- User Since
- Apr 11 2017, 7:18 AM (114 w, 8 h)
Nov 26 2018
Oct 24 2018
Added inline comments & an updated revision.
- naming change, SSE -> FPR
Oct 23 2018
Opened a new revision for this: https://phabricator.haskell.org/D5254
Oct 14 2018
It turns out that the padding should be slightly different for AArch64, because we use a disjoint set of registers for float and double (although Sx and Dx registers on AArch64 still alias to the Vx register).
Sep 30 2018
remove redundant isSSE def
May 20 2018
Now removing dependence on commit that was mistakenly pushed
May 16 2018
Haven't figured out how to land this (keeps getting rejected because of submodule keyword), but it's ready now.
- Merge branch 'master' into wip/T11295-part1
- update hadrian with support for llvm-passes
- readability tweaks
Updated patch with readability tweaks incoming.
May 15 2018
Mar 16 2018
Oh, great! I don't have any performance measurements yet since this is essentially just my first crack at the analysis.
Sep 21 2017
I agree with @bgamari in that I think this can be fixed in the LLVM backend itself. I will look at this bug very soon.
May 29 2017
May 20 2017
May 19 2017
@angerman sounds good to me, thanks for looking into this!
@angerman As far as I know, opt will not choose an appropriate datalayout for the given target triple... instead it will fall back on defaults that do not take the target into consideration :
May 18 2017
So far, the only thing that stuck out is the inline comment I've added about datalayouts and opt. I'll give this a change set a deeper look soon.
May 11 2017
One problem with going "clang only" in the current codebase crops up when compiling without optimizations, because clang -O0 will spend time applying passes that are irrelevant *, instead of only mem2reg and globalopt as we do now with opt. As you mentioned on the mailing list , -O0 increases the compile time by 200% in comparison. I figure the priority for GHC in this configuration is compile-time.
Yes, that's the reason for opt_lvl = max 1 (min 3 $ optLevel dflags). With clang, we wouldn't have -O0. I'm not fond of this either...
May 10 2017
I see that the opposition to this change is rather stark. I hope that an additive patch
will provide the following two pipelines will be received more positively.
-> opt -> llc -> mangler -> as and [-> opt] -> clang.