similar to: What is ConstantExpr?

On Sun, Mar 15, 2015 at 4:34 PM Olivier Sallenave <ol.sall at gmail.com> wrote: > Hi Daniel, > > Thanks for your feedback. I would prefer not to write a new AA. Can't we > directly implement that traversal in BasicAA? > Can I ask why? Outside of the "well, it's another pass", i mean? BasicAA is stateless, so you can't cache, and you really don't

I found a something that I quite not understand when compiling a common piece of code using the -Os flags. I found it while testing my own backend but then I got deeper and found that at least the x86 is affected as well. This is the referred code: char pp[3]; char *scscx = pp; int tst( char i, char j, char k ) { scscx[0] = i; scscx[1] = j; scscx[2] = k; return 0; } The above gets

Hi all, opt and opt + llc generate the difference aarch64 asm code for the following LLVM code. Is it intended behavior? I expected (A) because I cast %p from i192* to i64*. The information is dropped by opt and 8-byte padding is inserted or I write a bad code? % cat a.ll define void @store0_to_p4(i192* %p) { %p1 = bitcast i192* %p to i64* %p2 = getelementptr i64, i64* %p1, i64 3 %p3 =

The test case that you added in this revision fails on several of the power buildbots (for example, http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20127) and also when I build it locally: FAIL: Clang :: CodeGenCXX/main-norecurse.cpp (2951 of 27722) ******************** TEST 'Clang :: CodeGenCXX/main-norecurse.cpp' FAILED ******************** Script: --

Hello all, There is a missing vectorization opportunity issue with clang 4.0 with the file attached. Indeed, when compiled with -O2, the "op_distance" function get vectorized, but not the "op" one. For information, this test case has been reduced from a file generated by the Pythran compiler (https://github.com/serge-sans-paille/pythran). If we take a look at the generated

Hal Finkel <hfinkel at anl.gov> wrote on 16.03.2015 17:56:20: > If you want to do it at a clang level, the right thing to do is to > fixup the ABI lowerings for pointers to keep them pointers in this case. > So this is an artifact of the way that we pass structures, and > constructing a general solution at the ABI level might be tricky. > I've cc'd Uli, who did most

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "deadal nix" <deadalnix at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, August 19, 2015 7:24:28 PM > Subject: Re: [llvm-dev] [RFC] Aggreate load/store, proposed plan > > Hi, > > To be sure,

On Fri, Jan 2, 2015 at 2:20 AM, David Majnemer <david.majnemer at gmail.com> wrote: > > > On Fri, Jan 2, 2015 at 1:58 AM, Vadim Chugunov <vadimcn at gmail.com> wrote: > >> Hi! >> LLVM has a class, ConstantExpr, that is very handy for compile-time >> evaluation of const expressions. Unfortunately I cannot find any methods >> in it that would be

> On 2015-Nov-05, at 08:31, Aaron Ballman <aaron at aaronballman.com> wrote: > > On Thu, Nov 5, 2015 at 11:26 AM, James Molloy <james at jamesmolloy.co.uk> wrote: >> Ah I see. >> >> I can't think of a way that would help users in any particular way offhand. >> I hadn't considered exposing it to clang users - do you think there is merit

On 4/4/2011 6:45 PM, Eli Friedman wrote: > On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> wrote: >> >>> Hi, >>> Is it correct to convert, >>> %196 = load i32* %195, align 8 ;<i32> [#uses=1] >>> %197 = zext i32 %196 to i64 ;<i64> [#uses=1] >>> %198 =

When I compile this LLVM IR…. @0 = private constant [19 x i8] c"V4main10Brightness\00", section "__TEXT,__swift3_typeref, regular, no_dead_strip" @1 = private constant [9 x i8] c"Vs5UInt8\00", section "__TEXT,__swift3_typeref, regular, no_dead_strip" @2 = private constant [18 x i8] c"currentBrightness\00", section "__TEXT,__swift3_reflstr,

Yes, the full test case is: static int x = 100; int y = whatever; int main() { x = -101; y = whatever that's not whatever above; printf("%d\n", y); printf("%d\n", x); return 0; } You are correct, in the above test case the globalopt does not make the transformation.... however, I think the original issue still stands, it really shouldn't be doing it

Hi Duncan, Thanks for pointing out my mistake. I will reword my questions. //C code int var1; //global int a, b; foo(a, b); bar(c); generates following //LLVM IR %1 = load a; %2 = load b; call foo(%1, %2) call bar(@var1) CallInst.getOperand(1).getNameStr() on foo, returns null, but on bar returns var1. Similarly, for call void @p_ptr(i64 ptrtoint (%struct.my_struct* @abc to i64)) nounwind,

On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > > >> Hi, >> Is it correct to convert, >>   %196 = load i32* %195, align 8                  ; <i32> [#uses=1] >>   %197 = zext i32 %196 to i64                     ; <i64> [#uses=1] >>   %198 = ptrtoint i8* %193 to i64                 ; <i64> [#uses=1]

On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 6, 2010, at 7:35 PM, Talin wrote: > > After to speaking to Devang and a number of other people at the developer's > conference, I was able to make some forward progress on getting debugging to > work. I'm now able to actually single-step through my program and set > breakpoints,

----- Original Message ----- > From: "deadal nix" <deadalnix at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, August 21, 2015 1:24:04 AM > Subject: Re: [llvm-dev] [RFC] Aggreate load/store, proposed plan >

I have a question about when we should apply these pointer aliasing rules. Do the rules tell us when a load/store is safe? "Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior is undefined." So this means the conversion discussed here is still safe in terms of memory safety, but its meaning after conversion

----- Original Message ----- > From: "deadal nix" <deadalnix at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, August 20, 2015 4:09:17 PM > Subject: Re: [llvm-dev] [RFC] Aggreate load/store, proposed plan >

John, you are right. I 'browsed' the doxygen's inheritance diagram. Shouldn't I then be able to cast Constant * to Value*? Plugging the retrieved Constant* (from ConstantExpr::getGetElementPtr) into Instruction->setOperand compiles, but gives me an assertion failure at runtime. I have no access to the code at the moment. I will gather more information possibly tomorrow.

On 07/24/2015 03:42 AM, Benjamin Kramer wrote: >> On 24.07.2015, at 08:06, zhi chen <zchenhn at gmail.com> wrote: >> >> It seems that that it's hard to vectorize int64 in LLVM. For example, LLVM 3.4 generates very complicated code for the following IR. I am running on a Haswell processor. Is it because there is no alternative AVX/2 instructions for int64? The same thing