search for: codegenprep

...;Hal Finkel" <hfinkel at anl.gov> >>>> Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> >>>> Sent: Wednesday, November 20, 2013 7:48:13 PM >>>> Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare >>>> >>>> >>>> On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>>> >>>>> ----- Original Message ----- >>>>>> From: "Evan Cheng" <evan.cheng at apple.com> >>>&gt...

...purpose of the `llvm.$op.with.overflow` intrinsics. Three solutions I can think of: * if they're a convenience useful only for better codegen, can the transform that instcombine is doing currently (transforming compares to `extractvalue` of a `.with.overflow` intrinsic) be moved to CodeGenPrep? * if they're something more fundamental, then maybe they should to be promoted to an instruction? They've been around since at least llvm 2.6 as far as I can tell. Personally, I seriously doubt this is a good idea, given that the semantics of these intrinsics can be complet...

...t; To: "Hal Finkel" <hfinkel at anl.gov> >>> Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> >>> Sent: Wednesday, November 20, 2013 7:48:13 PM >>> Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare >>> >>> >>> On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> >>>> ----- Original Message ----- >>>>> From: "Evan Cheng" <evan.cheng at apple.com> >>>>> To: "Junbum L...

...re, and I think > that's the right thing to do. However, the problem you point out is a > general one. Can you please explain why the MachineLICM pass is not able to > hoist the redundant parts of the addressing computation out of the loop? We > might also want to adjust for this in CodeGenPrep (CGP already has > addressing-mode aware GEP splitting logic, although not quite for this > case). > > Hi Hal, MachineLICM is not able to hoist anything because the address mode is not loop invariant. Here is a reduction of the code I am talking about. extern const unsigned phasor[...

> For the loads, I'm must less sure. Why can't we represent the loads as select(mask, load(addr), passthru)? It is true, that the load might get separated from the select so that isel might not see it (because isel if basic-block local), but we can add some code in CodeGenPrep to fix that for targets on which it is useful to do so (which is a more-general solution than the intrinsic anyhow). What do you think? We generate the vector-masked-intrinsic on IR-to-IR pass. It is too far from instruction selection. We'll need to guarantee that all subsequent IR-to-IR passe...

...m> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> >> Sent: Wednesday, November 20, 2013 7:48:13 PM >> Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare >> >> >> On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >>> ----- Original Message ----- >>>> From: "Evan Cheng" <evan.cheng at apple.com> >>>> To: "Junbum Lim" <junbums at gmai...

...heng at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> > Sent: Wednesday, November 20, 2013 7:48:13 PM > Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare > > > On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ----- Original Message ----- > >> From: "Evan Cheng" <evan.cheng at apple.com> > >> To: "Junbum Lim" <junbums at gmail.com> > >> C...

On Sat, Mar 02, 2019 at 07:34:50PM -0800, Tim Northover wrote: > The biggest difference and problem I see would be building the thing, > since the target's headers are going to be needed, but they're > private. That means they're not shipped with LLVM so you'd need the > source (and an active build directory for the TableGenerated files, >

...ended up with the following set of instructions: catcblock, catchret, cleanupblock, cleanupret, terminateblock Of these, I've locally added basic support for catchblock, catchret and cleanupret. I'm working on cleanupblock and terminateblock as we speak. We'll still need to hook up CodeGenPrep and SDAG up to the new representation. Extra hands will be appreciated auditing LLVM's optimizations to ensure that they do not miscompile in the face of our new instructions. > > Thanks > > -Joseph > > > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvm...

...ne (which has the job of canonicalizing the IR). >> >> We should, however, pull these apart somewhere, and probably in some way >> that is address-mode aware. I'd recommend trying to split non-free (via the >> addressing-mode) loop-invariant parts of GEPs out of loops in CodeGenPrep. >> > > Thanks, Hal. I'll have a look at CGP to see how this might be done. It's > a little more complicated than just pulling the GEP apart, there needs to > be a loop-invariant-aware reassociation to undo the damage done by the > initial merge. > So, this is in...

...D field in Function we use for IntrinsicID to make that fast. Looking into a compile time issue during codegen (LLC) for a large IR file, I came across something interesting.  Due to the presence of a very large number of intrinsics in the particular example, we were spending almost 30% of time in CodeGenPrep::optimizeCallInst, and within that, almost all of it in the FortifiedLibCallSimplifier.  Now, since the IR file in question has no fortified libcalls, that seemed a bit odd. Looking into, it turns out that figuring out that an arbitrary direct call is *not* a call to a LibCall requires a full name...

Hello I am not sure I understand the logic for merging GEPs in InstructionCombining.cpp: static bool shouldMergeGEPs(GEPOperator &GEP, GEPOperator &Src) { // If this GEP has only 0 indices, it is the same pointer as // Src. If Src is not a trivial GEP too, don't combine // the indices. if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() &&

----- Original Message ----- > From: "Evan Cheng" <evan.cheng at apple.com> > To: "Junbum Lim" <junbums at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, November 20, 2013 7:01:49 PM > Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare > > > On Nov 20, 2013, at 3:10 PM, Junbum Lim <junbums at gmail.com> wrote: > > > > > > > When multiple GEPs or other operations are used for the address > > calculation, OptimizeMemoryInst() performs address matching and > > determines a fina...

...o fold address computation into LDRs and STRs. However, OptimizeMemoryInst() seems to do this transformation even when the address calculation derived from a single GEP, resulting in poor alias analysis because GEP is no longer used. I don't follow your last statement. How does this impact AA? CodeGenPrep is run late, after AA is done. Evan > > So, do you think it is a possible workaround to sink a GEP without converting it into a set of integer operations (ptrtoint/add/inttoptr) if the address mode is derived only from a single GEP. > > Thanks, > Jun > > > On Nov 12, 2...

...library call. I am a bit confused by the problem you are trying to solve. Are you specifically interested in lowering for constant lengths greater than a legal size? (i.e. do you need the loop?) If so, there are two approaches you might consider: - Expand the memcmp call into the loop form in CodeGenPrep (or a similar timed pass) where working with multiple basic blocks is much easier. Long term, the "right place" for this type of thing is clearly GlobalISEL, but we have a number of other such hacks in lowering today and continuing to build off of that seems reasonable. - Emit the no...

...ter isel is not realistic. For the loads, I'm must less sure. Why can't we represent the loads as select(mask, load(addr), passthru)? It is true, that the load might get separated from the select so that isel might not see it (because isel if basic-block local), but we can add some code in CodeGenPrep to fix that for targets on which it is useful to do so (which is a more-general solution than the intrinsic anyhow). What do you think? Thanks again, Hal > > Thank you. > > - Elena and Ayal > > > > ---------------------------------------------------------------------...

...right thing to do. However, the problem you > > point out is a general one. Can you please explain why the > > MachineLICM pass is not able to hoist the redundant parts of the > > addressing computation out of the loop? We might also want to > > adjust > > for this in CodeGenPrep (CGP already has addressing-mode aware GEP > > splitting logic, although not quite for this case). > > > > > > > > > > Hi Hal, > > > > > > MachineLICM is not able to hoist anything because the address mode > > is > > not loop i...

...Combine (which has the job of > canonicalizing the IR). > > We should, however, pull these apart somewhere, and probably in some > way that is address-mode aware. I'd recommend trying to split > non-free (via the addressing-mode) loop-invariant parts of GEPs out > of loops in CodeGenPrep. > > > > > > > Thanks, Hal. I'll have a look at CGP to see how this might be done. > It's a little more complicated than just pulling the GEP apart, > there needs to be a loop-invariant-aware reassociation to undo the > damage done by the initial merge. &...

...* PromoteIntegers legalizes integer types (e.g. i30 is converted to >> i32). >> > > Does it split up too-wide integers? Do we really want another integer > legalization framework in LLVM? I am actually interested in doing (partial) > legalization in the IR during lowering (codegenprep time) in order to > simplify the backend, but I don't think we should develop such a framework > independently of the legalization currently used in the backends. > > >> >> * Module-level lowering: This implements, at the IR level, >> functionality that is tradit...

...#39;t we represent the > > > loads > > > as select(mask, load(addr), passthru)? It is true, that the load > > > might get separated from the select so that isel might not see it > > > (because isel if basic-block local), but we can add some code in > > > CodeGenPrep to fix that for targets on which it is useful to do > > > so > > > (which is a more-general solution than the intrinsic anyhow). > > > What > > > do you think? > > > > We generate the vector-masked-intrinsic on IR-to-IR pass. It is too > > far...