kavon (Kavon Farvardin)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 11 2017, 7:18 AM (106 w, 11 h)

Recent Activity

Nov 26 2018

kavon added a comment to D5204: EXPERIMENTAL: different codegen for tag-check on entering (#8905).

What happens along the non-evaluated code path is:

  • We evaluate x1, spilling and reloading x2/x3 across the call.
  • Evaluate x2, spilling/reloading the unpacked x1 value and x3.
  • Evaluate x3, spilling/reloading the unpacked x1/x2 values.

    In contrast in the old approach each value got spilled at most once and then loaded at the use site.
Nov 26 2018, 2:29 PM

Oct 24 2018

kavon added a comment to D5254: Fix for T14251 on ARM.

Added inline comments & an updated revision.

Oct 24 2018, 3:50 PM
kavon updated the diff for D5254: Fix for T14251 on ARM.
  • naming change, SSE -> FPR
Oct 24 2018, 3:46 PM

Oct 23 2018

kavon added a comment to D5190: Multiple fixes / improvements for LLVM backend.

Opened a new revision for this: https://phabricator.haskell.org/D5254

Oct 23 2018, 5:56 PM
kavon updated the Trac tickets for D5254: Fix for T14251 on ARM.
Oct 23 2018, 5:54 PM
kavon updated the Trac tickets for D5254: Fix for T14251 on ARM.
Oct 23 2018, 5:17 PM
kavon updated the test plan for D5254: Fix for T14251 on ARM.
Oct 23 2018, 5:15 PM
kavon created D5254: Fix for T14251 on ARM.
Oct 23 2018, 5:13 PM

Oct 14 2018

kavon added a comment to D5190: Multiple fixes / improvements for LLVM backend.

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).

Oct 14 2018, 11:11 AM

Sep 30 2018

kavon retitled D5190: Multiple fixes / improvements for LLVM backend from Multiple fixes / improvements for LLVM backend #13904 to Multiple fixes / improvements for LLVM backend.
Sep 30 2018, 7:14 PM
kavon updated the diff for D5190: Multiple fixes / improvements for LLVM backend.

remove redundant isSSE def

Sep 30 2018, 7:10 PM
kavon created D5190: Multiple fixes / improvements for LLVM backend.
Sep 30 2018, 7:03 PM

May 20 2018

kavon updated the diff for D4695: Extract hard-coded LLVM opt flags into a file.

Now removing dependence on commit that was mistakenly pushed
to git.haskell.org/hadrian.git.

May 20 2018, 5:13 PM

May 16 2018

kavon added a comment to D4695: Extract hard-coded LLVM opt flags into a file.

The PR is in now: https://github.com/snowleopard/hadrian/commit/85f2506f87c890ba985825c74dea92c10e80152e

May 16 2018, 6:37 PM
kavon added a comment to D4695: Extract hard-coded LLVM opt flags into a file.

Haven't figured out how to land this (keeps getting rejected because of submodule keyword), but it's ready now.

May 16 2018, 4:39 PM
kavon updated the diff for D4695: Extract hard-coded LLVM opt flags into a file.
  • Merge branch 'master' into wip/T11295-part1
May 16 2018, 4:09 PM
kavon updated the diff for D4695: Extract hard-coded LLVM opt flags into a file.
  • update hadrian with support for llvm-passes
May 16 2018, 3:56 PM
kavon updated the diff for D4695: Extract hard-coded LLVM opt flags into a file.
  • readability tweaks
May 16 2018, 3:50 PM
kavon added a comment to D4695: Extract hard-coded LLVM opt flags into a file.

Updated patch with readability tweaks incoming.

May 16 2018, 3:25 PM

May 15 2018

kavon created D4695: Extract hard-coded LLVM opt flags into a file.
May 15 2018, 3:01 PM

Mar 16 2018

kavon added a comment to D4505: [WIP] Optimizing tail-recursive functions.

Oh, great! I don't have any performance measurements yet since this is essentially just my first crack at the analysis.

Mar 16 2018, 4:08 PM
kavon retitled D4505: [WIP] Optimizing tail-recursive functions from Optimizing tail-recursive functions to [WIP] Optimizing tail-recursive functions.
Mar 16 2018, 1:15 PM
kavon updated the summary of D4505: [WIP] Optimizing tail-recursive functions.
Mar 16 2018, 1:09 PM
kavon updated the summary of D4505: [WIP] Optimizing tail-recursive functions.
Mar 16 2018, 1:09 PM
kavon updated the summary of D4505: [WIP] Optimizing tail-recursive functions.
Mar 16 2018, 1:07 PM
kavon created D4505: [WIP] Optimizing tail-recursive functions.
Mar 16 2018, 1:03 PM

Sep 21 2017

kavon added a comment to D4003: Keep the original live register set live after proc point splitting (make CmmProc and corresponding CmmCall's `live` registers match up).

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.

Sep 21 2017, 11:06 AM

May 29 2017

kavon added a comment to D3352: Clean up opt and llc.

Something in our opt -> llc -> mangler -> as pipeline results in bad relocations being generated on aarch64.

May 29 2017, 5:25 AM

May 20 2017

kavon accepted D3352: Clean up opt and llc.

LGTM

May 20 2017, 9:31 AM

May 19 2017

kavon added a comment to D3352: Clean up opt and llc.

@angerman sounds good to me, thanks for looking into this!

May 19 2017, 10:40 AM
kavon added a comment to D3352: Clean up opt and llc.
In D3352#102253, @kavon wrote:

And passing this via -default-data-layout= to opt?

Sure, though I think the flag is is actually -data-layout=<layout-string>

May 19 2017, 8:12 AM
kavon added a comment to D3352: Clean up opt and llc.

Can we agree on a separate file:

May 19 2017, 8:12 AM
kavon requested changes to D3352: Clean up opt and llc.

@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 [1]:

May 19 2017, 4:15 AM

May 18 2017

kavon added a comment to D3352: Clean up opt and llc.

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 18 2017, 1:03 PM

May 11 2017

kavon updated subscribers of D3352: Clean up opt and llc.

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 [1], -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 11 2017, 5:57 AM

May 10 2017

kavon added a comment to D3352: Clean up opt and llc.
In D3352#101260, @kavon wrote:

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.

Yes, I think it's fine to have GHC detect a compatible version of clang and try to use that if opt/llc are not available. As long as we do not remove the use of opt/llc, which should be prioritized first if available.

I fear we don't see eye to eye on this. I would prefer to use the clang only route, and opt + clang if -opt_lo is specified, and the opt+llc route if opt_lc is provided. (Or some global flag is set which defines
which route the user wants ghc to take. With the current codebase I do not see the benefit of using opt, when using clang with any -O > 0. This may change once we know which optimization passes we
definitely want to run.

May 10 2017, 10:20 AM
kavon added a comment to D3352: Clean up opt and llc.

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.

May 10 2017, 8:19 AM
kavon added a comment to D3352: Clean up opt and llc.

I don't think this change should be merged into GHC.

May 10 2017, 5:06 AM