search for: aemerson

...adding a convoluted command line option (‘-mllvm -global-isel=0’?) Combining the 2 observations above, I think it’s better to do the switch shortly after a release branch is taken, rather than just before it. I hope that makes sense? Thanks, Kristof On 15 Dec 2017, at 19:33, Amara Emerson <aemerson at apple.com<mailto:aemerson at apple.com>> wrote: Hi Kristof, We’ve had some more internal discussion and we think that we can, and should, still aim to enable this by default before the release. We have a month of testing time available to shake out critical issues which is normally en...

...ch. At this point, I’d aim to flip the switch shortly after the creation of the 6.0.0 release branch, so that GlobalISel can harden a bit more enabled-by-default on trunk before it goes into an LLVM release (presumably 7.0.0 then). Thanks, Kristof > On 11 Dec 2017, at 17:08, Amara Emerson <aemerson at apple.com> wrote: > > As of r320388 we’ve either fixed the blocker bugs or disabled big-endian on GISel, falling back to SDAG. Fixing at least one of the big-endian issues will need use to change the way we handle aggregates, which will take a bit longer (it’s next on my list of things...

> On May 4, 2020, at 2:01 PM, Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On May 1, 2020, at 14:00, Amara Emerson <aemerson at apple.com <mailto:aemerson at apple.com>> wrote: >> >> The other thing we could do is to assign speculative regbanks to vregs during translation (if the target wants to opt-in), and then RBS can finalize the regbanks, changing some if it deems it necessary/optimal. > &g...

...d be easily fixable. > > For the record, I was doing the attribute check in lowerFormalArgument IIRC. I.e., something that is called for every single function at the beginning of the GISel pipeline. > > Cheers, > -Quentin > >> On May 5, 2020, at 2:48 PM, Amara Emerson <aemerson at apple.com> wrote: >> >> Hi all. >> >> I’m trying to get GlobalISel to work better with LTO. At the moment if you enable it via -fglobal-isel, it only adds the -mllvm -global-isel and related options to the cc1 invocation. With LTO, that doesn’t work as we need to enc...

On 18 Dec 2017, at 15:11, Amara Emerson <aemerson at apple.com<mailto:aemerson at apple.com>> wrote: On Dec 18, 2017, at 12:37 PM, Kristof Beyls <Kristof.Beyls at arm.com<mailto:Kristof.Beyls at arm.com>> wrote: Hi Amara, My reasons for preferring the switch to happen after the release branch is based on the following obse...

...Patch should be incoming to enable it later today. > > Thanks, > Amara > >> On Dec 18, 2017, at 3:25 PM, Kristof Beyls <Kristof.Beyls at arm.com <mailto:Kristof.Beyls at arm.com>> wrote: >> >>> >>> On 18 Dec 2017, at 15:11, Amara Emerson <aemerson at apple.com <mailto:aemerson at apple.com>> wrote: >>> >>> >>>> On Dec 18, 2017, at 12:37 PM, Kristof Beyls <Kristof.Beyls at arm.com <mailto:Kristof.Beyls at arm.com>> wrote: >>>> >>>> Hi Amara, >>>> >&g...

Matt: that’s fair. We’re generally apprehensive of option 2 as well. Eli: Yes, currently we believe that aarch64.neon.addp is the only arm64 one affected, but we don’t know how prevalent this is on other targets. Splitting it is certainly possible combined with the autoupgrader. If disambiguating the intrinsics is the preferred solution, then I think we should also have the langref also specify

...mponents more modular, reusable, and easier to maintain. Moving things where they actually belong is part of that picture. That makes it a lot easier for us to place those things within VPlan infrastructure and explain why that's the best place. Thanks, Hideki -----Original Message----- From: aemerson at apple.com [mailto:aemerson at apple.com] Sent: Friday, January 05, 2018 3:38 PM To: Saito, Hideki <hideki.saito at intel.com> Cc: llvm-dev at lists.llvm.org; Hal Finkel <hfinkel at anl.gov>; Demikhovsky, Elena <elena.demikhovsky at intel.com>; Amara Emerson <amara.emerson a...

...le it later today. >> >> Thanks, >> Amara >> >>> On Dec 18, 2017, at 3:25 PM, Kristof Beyls <Kristof.Beyls at arm.com <mailto:Kristof.Beyls at arm.com>> wrote: >>> >>>> >>>> On 18 Dec 2017, at 15:11, Amara Emerson <aemerson at apple.com <mailto:aemerson at apple.com>> wrote: >>>> >>>> >>>>> On Dec 18, 2017, at 12:37 PM, Kristof Beyls <Kristof.Beyls at arm.com <mailto:Kristof.Beyls at arm.com>> wrote: >>>>> >>>>> Hi Amara, >...

...store/gather/scatter. Would need some extensibility, and I think that should be discussed as a separate review. Stay Tuned. Hideki -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Saturday, January 06, 2018 9:20 PM To: Saito, Hideki <hideki.saito at intel.com>; aemerson at apple.com Cc: llvm-dev at lists.llvm.org; Demikhovsky, Elena <elena.demikhovsky at intel.com>; Amara Emerson <amara.emerson at arm.com>; Stotzer, Eric <estotzer at ti.com>; Nemanja Ivanovic <nemanja.i.ibm at gmail.com>; Kreitzer, David L <david.l.kreitzer at intel.com&...

> On May 1, 2020, at 10:28 AM, Arsenault, Matthew <Matthew.Arsenault at amd.com> wrote: > > [AMD Public Use] > > > It seems to me like you're looking for a workaround for the fact that nobody has put any serious optimization effort into RegBankSelect Practically speaking, we have a compile time budget, and spending that on reconstructing information which we

...eck for any significant impact). The intrinsics should be scalarized on all targets without support (by lib/CodeGen/ScalarizeMaskedMemIntrin.cpp which is scheduled by default in TargetPassConfig::addIRPasses). -Hal > > Thanks, > Hideki > > -----Original Message----- > From: aemerson at apple.com [mailto:aemerson at apple.com] > Sent: Friday, January 05, 2018 3:38 PM > To: Saito, Hideki <hideki.saito at intel.com> > Cc: llvm-dev at lists.llvm.org; Hal Finkel <hfinkel at anl.gov>; Demikhovsky, Elena <elena.demikhovsky at intel.com>; Amara Emerson <a...

...> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > No we still use the shuffle expansion which is why the issue isn't > unique to the intrinsic. > > ~Craig > > > On Thu, Apr 9, 2020 at 10:21 AM Amara Emerson <aemerson at apple.com > <mailto:aemerson at apple.com>> wrote: > > Has x86 switched to the intrinsics now? > >> On Apr 9, 2020, at 10:17 AM, Craig Topper >> <craig.topper at gmail.com <mailto:craig.topper at gmail.com>> wrote: >>...

No we still use the shuffle expansion which is why the issue isn't unique to the intrinsic. ~Craig On Thu, Apr 9, 2020 at 10:21 AM Amara Emerson <aemerson at apple.com> wrote: > Has x86 switched to the intrinsics now? > > On Apr 9, 2020, at 10:17 AM, Craig Topper <craig.topper at gmail.com> wrote: > > That recent X86 bug isn't unique to the intrinsic. We generate the same > code from this which uses the shuffle sequenc...

...8 PM Craig Topper via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> No we still use the shuffle expansion which is why the issue isn't unique >> to the intrinsic. >> >> ~Craig >> >> >> On Thu, Apr 9, 2020 at 10:21 AM Amara Emerson <aemerson at apple.com> wrote: >> >>> Has x86 switched to the intrinsics now? >>> >>> On Apr 9, 2020, at 10:17 AM, Craig Topper <craig.topper at gmail.com> >>> wrote: >>> >>> That recent X86 bug isn't unique to the intrinsic. We generat...

...574 > > -Oz -ftrivial-auto-var-init=pattern > dse - Number of stores deleted 3420 > dsem - Number of deleted writes 1637 This looks great! Do you have a patch ready to go? > From: Amara Emerson <aemerson at apple.com <mailto:aemerson at apple.com>> > Date: Tue, Apr 16, 2019 at 12:10 PM > To: Vitaly Buka > Cc: Alexander Potapenko, llvm-dev, Peter Collingbourne > > Can you post numbers for how many stores get eliminated from CTMark? > >> On Apr 16, 2019, at 11:45 AM...

Can you post numbers for how many stores get eliminated from CTMark? > On Apr 16, 2019, at 11:45 AM, Vitaly Buka <vitalybuka at google.com> wrote: > > I tried -Os and effect of new approach significantly increases. > I run regular DSE and immediately myDSE. With -Os myDSE removes more than 50% of DSE number. > Which is expected as -Os inlines less and regular DSE can't

Hi all. I’m trying to get GlobalISel to work better with LTO. At the moment if you enable it via -fglobal-isel, it only adds the -mllvm -global-isel and related options to the cc1 invocation. With LTO, that doesn’t work as we need to encode codegen options into the bitcode, usually via function attributes. Does anyone have any ideas on how to achieve this? The only way I can see it working is if

> On 5 Jan 2018, at 21:01, Saito, Hideki via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > All, > > I'm trying to refactor LoopVectorize such that it has better conformance to VPlan vision going forward > (http://www.llvm.org/docs/Proposals/VectorizationPlan.html). All VP*Recipe class definitions are now > moved to VPlan.h, and I have a patch under review

All, I'm trying to refactor LoopVectorize such that it has better conformance to VPlan vision going forward (http://www.llvm.org/docs/Proposals/VectorizationPlan.html). All VP*Recipe class definitions are now moved to VPlan.h, and I have a patch under review to move LoopVectorizationPlanner class out of LoopVectorize.cpp (https://reviews.llvm.org/D41420). Next thing I'm working on is