similar to: GlobalAddress lowering strategy

Hi All, In order to confine the scope of a local variable allocated using "alloca", we had written a pass named 'undeflocal'. This helps avoid pseudo phi nodes inserted because of the path (carrying an undefined value) starting from the "entry" block. This unwanted phi instruction was preventing some of the optimizations from getting triggered later on. For example,

Hello, Brief background: We are trying to support 64 bit pointers in RISCV 32 bit backend http://lists.llvm.org/pipermail/llvm-dev/2019-June/132805.html To pass the legalizer we plan to break the 64 bit GlobalAddress into 32 bit GlobalAddress having the other 32 bit glued to the node. We could not find a direct way to convert the 64 bit GlobalAddress Node into a 32 bit node. For a GlobalAddress

> > I don't think there's a real shortage of those, but I confess I'm not > sure why that's related. You'd need a representation for the LUI and > ADDI after instruction selection anyway. Yeah at the end we need a representation for LUI and ADDI. We were trying to break the 64 bit address from GlobalAddress node into two i32 register. We will add custom load/store

Hi All, The PRE or GVNPRE is not effective for the below use case. int sum; int phi =30; void f (int i, int *a) { if ((a[i] << (1)) > -15) sum =(phi+ 0x7fffffffL )/ a[i]; if ((a[i] << (2)) > -15) sum =(phi + 0x7fffffffL) /a[i]; } respective asm (clang on trunk ) #clang -O3 -S test.c BB#0: # %entry pushl %edi pushl %esi

On Thu, Jul 11, 2019 at 10:21 PM Tim Northover <t.p.northover at gmail.com> wrote: > On Thu, 11 Jul 2019 at 17:16, Reshabh Sharma <reshabhsh at gmail.com> wrote: > > We thought LUI and ADDI pair will be good to store the values in a i32 > register. > > With you so far, I think. To be explicit, to materialize a full 64-bit > pointer you'd need 4 instructions:

Every GlobalAddress has a GlobalValue, Every GlobalValue is a PointerType, Every PointerType has an AddressSpace. So is it ok to add a method getAddressSpace in GlobalAddressSDNode class itself? Currently we have to do GSDN->getGlobal()->getType()->getAddressSpace(). - Sanjiv

using `opt --print-after-all -O3` I see that EarlyCSE is interpreting the call to `ceil` and constant fold: *** IR Dump After Early CSE *** ; Function Attrs: nobuiltin nounwind define i1 @do_test() #2 { Entry: %0 = call fastcc float @ceil(float 0.000000e+00) #6 %1 = call fastcc float @ceil32(float 0.000000e+00) #6 %2 = fcmp fast oeq float 0.000000e+00, %1 ret i1 %2 } So just running `opt

On Mon, Jun 19, 2017 at 12:06 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > Hi, > > 2017-06-19 8:45 GMT-07:00 Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Greetings, >> >> I have a Zig implementation of ceil which is emitted into LLVM IR like >> this: >> >> ; Function Attrs: nobuiltin nounwind >> define

or like this %cmp4 = icmp eq i32 %rem, 0 br i1 %cmp4, label %if.then5, label %if.else7 On 14 August 2013 20:08, Rasha Omar <rasha.sala7 at gmail.com> wrote: > Hi All, > > How could I use BranchInst to implement for example > br label %if.else7 > br label %if.then5 > br i1 %cmp4, label %if.then5, label %if.else7 > > I can use BranchInst for only one

Your question isn't clear; please restate what specifically isn't working. -Eli On Wed, Aug 14, 2013 at 11:57 AM, Rasha Omar <rasha.sala7 at gmail.com> wrote: > or like this > > %cmp4 = icmp eq i32 %rem, 0 > > br i1 %cmp4, label %if.then5, label %if.else7 > > > On 14 August 2013 20:08, Rasha Omar <rasha.sala7 at gmail.com> wrote: > >> Hi

Hi All, How could I use BranchInst to implement for example br label %if.else7 br label %if.then5 br i1 %cmp4, label %if.then5, label %if.else7 I can use BranchInst for only one instruction but how could I compare between two branches Thanks -- * Rasha Salah Omar Msc Student at E-JUST Demonestrator at Faculty of Computers and Informatics Benha University* *

How could BranchInst be used to insert new branch between two basic blocks to get result like this example: br label %if.else br label %if.then br i1 %cmp1, label %if.then, label %if.else Thanks for your help On 14 August 2013 21:36, Eli Friedman <eli.friedman at gmail.com> wrote: > Your question isn't clear; please restate what specifically isn't working. > > -Eli

On Fri, 2004-06-18 at 10:13, Chris Lattner wrote: > Module::gbegin/gend iterate over the global variables, and ::begin/end > iterate over the functions, some of which may be prototypes. This confused Vladimir and I remember it confusing me when I was reviewing LLVM core a few months ago. Would it be worthwhile to consider naming these globals_begin/globals_end and

On Fri, 18 Jun 2004, Reid Spencer wrote: > On Fri, 2004-06-18 at 10:13, Chris Lattner wrote: > > > Module::gbegin/gend iterate over the global variables, and ::begin/end > > iterate over the functions, some of which may be prototypes. > > This confused Vladimir and I remember it confusing me when I was > reviewing LLVM core a few months ago. Would it be worthwhile to

sure, that's reasonable. I'll make the patch but later this weekend .. bigger fish to fry :) Reid. On Fri, 2004-06-18 at 22:44, Chris Lattner wrote: > On Fri, 18 Jun 2004, Reid Spencer wrote: > > On Fri, 2004-06-18 at 10:13, Chris Lattner wrote: > > > > > Module::gbegin/gend iterate over the global variables, and ::begin/end > > > iterate over the

On Thu, 17 Jun 2004, Vladimir Prus wrote: > > Hi, > here I am again with "why is this so" kind of a question. Among different > types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. > > For MO_GlobalAddress, we can get usefull information from the getGlobal() > method, which returns GlobalValue*. Wouldn'it it be better is >

Hi, here I am again with "why is this so" kind of a question. Among different types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. For MO_GlobalAddress, we can get usefull information from the getGlobal() method, which returns GlobalValue*. Wouldn'it it be better is MO_GlobalAddress be called MO_GlobalValue, for consistency? Second, MO_ExternalSymbol is used

On Tue, Nov 19, 2013 at 8:38 AM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Tue, Nov 19, 2013 at 8:25 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> Just moving this branch of the thread out of the review because I don't >> want to derail the review thread... >> >> Kostya - why are these two cases not optimization bugs in

On Thu, Jul 11, 2019 at 10:42 PM Tim Northover <t.p.northover at gmail.com> wrote: > On Thu, 11 Jul 2019 at 18:03, Reshabh Sharma <reshabhsh at gmail.com> wrote: > > Ah now I could see it more clearly. I was not sure that should I add > them (MO_LO32_LO and MO_LO32_HI), btw this was backup plan. Probably for > now we are going with this. I implemented them today and

Hello, I have a question regarding PGO instrumented BBs (I use IR-level instrumentation). It seems that instrumented BBs do not match between the two compilations for profile-gen and profile-use for some cases. Here is an example from SPECcpu 2006 lbm (a simple case consisting of just two modules). In the first compilation, we have 5 instrumentation points for the main function as follows: $