similar to: [LLVMdev] Annotating known pointer alignment

Hi Clemens, > I'm instrumenting IR by replacing loads and stores by calls to a library, which > I have compiled to bitcode such that inlining can take place. My problem is: If > I could retain the alignment information on the load/store, this would open many > optimization opportunities after inlining. Unfortunately, I don't know how. > > After thinking about it, and

Hi Duncan, thanks for your comments. >> First, consider this function: >> #include <stdint.h> >> uint64_t foo(uint64_t *bar) { >> *bar = 42; >> return (uint64_t)bar & 3; >> } >> >> Which is compiled to >> define i64 @foo(i64* %bar) nounwind uwtable ssp { >> store i64 42, i64* %bar, align 8 >>

Hi Clemens, > thanks for your comments. > >>> First, consider this function: >>> #include <stdint.h> >>> uint64_t foo(uint64_t *bar) { >>> *bar = 42; >>> return (uint64_t)bar & 3; >>> } >>> >>> Which is compiled to >>> define i64 @foo(i64* %bar) nounwind uwtable ssp {

Hi Duncan, >>> and instcombine adds the explicit alignment according to >>>> the langref (pref alignment). >>> >>> Without an explicit alignment means the ABI alignment in the case of >>> loads/stores. >> >> Yes, that second step was clear. Assuming you meant the "preferential >> alignment", according to the langref.

I see instcombine doing something I'm not sure is right. Incoming, I have this: %r29 = ptrtoint [71 x i64]* %"t$3" to i64 ; <i64> [#uses=1] %r30 = inttoptr i64 %r29 to i64* ; <i64*> [#uses=1] store i64 72057594037927936, i64* %r30, align 8 Outgoing, I have this: %r30 = getelementptr [71 x i64]* %"t$3", i32 0, i32 0 ; <i64*> [#uses=1] store i64

Hello, all. Recently we noticed a problem with function pointer alignment in LLVM: the value tracking analysis (specifically the 'computeKnownBits' function) uses function alignment to infer that the least significant bits of function pointers are known to be zero. Unfortunately, this is not correct for ARM targets: the least significant bit of a function pointer stores the ARM/Thumb

Hi all, We noticed a lot of unnecessary ptrtoint instructions that stand in way of some of our optimizations; the code pattern looks like this: bb1: %int1 = ptrtoint %struct.s* %ptr1 to i64 bb2: %int2 = ptrtoint %struct.s* %ptr2 to i64 %bb3: %phi.node = phi i64 [ %int1, %bb1 ], [%int2, %bb2 ] %ptr = inttoptr i64 %phi.node to %struct.s* In short, the pattern above arises due to: 1.

If you're able to reproduce the infinite loop with -O3 then you should be able to dump out the IR that causes `opt -instcombine` to infloop, unless the bug is truly esoteric (e.g. only caused by a specific use-list ordering). Maybe take a closer look at the output from `opt -print-before-all -O3`? Alternatively you can use bugpoint to minimize the IR to get a small reproducer that causes

Hello all, This is a proposal for reducing # of ptrtoint/inttoptr casts which are not written by programmers but rather generated by LLVM passes. Currently the majority of ptrtoint/inttoptr casts are generated by LLVM; when compiling SPEC 2017 with LLVM r348082 (Dec 2 2018) with -O3, the output IR contains 22,771 inttoptr instructions. However, when compiling it with -O0, there are only 1048

Using LLVM ToT and Hal's helpful slide deck [1], I've been trying to use `llvm.assume` to communicate pointer alignment guarantees to vector load and store instructions. For example, in [2] %5 and %9 are guaranteed to be 32-byte aligned. However, if I run this IR through `opt -O3 -datalayout -S`, the vectorized loads and stores are still 1-byte aligned [3]. What's going wrong? Do I

On Mon, Jan 14, 2019 at 9:36 AM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > While I'm very interested in the end result here, I have some questions > that don't seem well answered yet around pointer subtraction... > > First and foremost - how do you address correctness issues here? Because > the subtraction `A - B` can escape/capture more

Hello Chandler, > ``` > void f(int *arr1, int *arr2, int length) { > intptr_t rel_offset = arr2 - arr1; > int *arr1_end = arr1 + length; > for (int *p = arr1; p < arr1_end; p += sizeof(int)) { > do_something(p, p + rel_offset); > } > } > ``` > > For example, a common loop optimization technique is something like the following in *pseudocode* (note

Hello Chandler, > First and foremost - how do you address correctness issues here? Because the subtraction `A - B` can escape/capture more things. Specifically, if one of `A` or `B` is escaped/captured, the > subtraction can be used to escape or capture the other pointer. So *some* of the conservative treatment is necessary. What is the plan to update all the analyses to remain correct?

Hello, As I can see, recently LLVM switched to using assume bundles to encode alignment information: https://reviews.llvm.org/rG78de7297abe2e8fa782682168989c70e3cb34a5c However, it seems that the ValueTracking cannot understand the new format. As an example, consider compilation of the following reproducer with clang-11 (old assume format) and clang-trunk (assume bundles): #include

On Mon, Jan 14, 2019 at 4:51 PM Chandler Carruth <chandlerc at gmail.com> wrote: > > On Mon, Jan 14, 2019, 15:59 Mehdi AMINI <joker.eph at gmail.com wrote: > >> >> >> On Mon, Jan 14, 2019 at 9:36 AM Chandler Carruth via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> While I'm very interested in the end result here, I have

My general feeling is this: No optimizations should be creating int2ptr/ptr2int. We really need to fix them all. They should use pointer casts and i8* GEPs. This has, unfortunately, been a problem for a long time. As Johannes says, optimizing int2ptr/ptr2int is very tricky. In part, becaue all dependencies, including implicit control dependencies, end up being part of the resulting aliasing

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

Hi Andy, Andrew Trick wrote: > Sanjoy, > > This looks very close to my understanding of the statepoint design trajectory when you first introduced it. It’s great that you followed through and took the time to formalize the IR semantics. It’s been a couple years since I’ve thought about it so I may ask some obtuse questions. > > I think he subject line is wrong though! Did

Hi Nick, On Tue, 26 Oct 2010, Nick Lewycky wrote: > Joel E. Denny wrote: > > Given this LLVM assembly: > > > > @a = global i8* getelementptr (i8* null, i64 mul (i64 ptrtoint (i32* > > getelementptr (i32* null, i32 1) to i64), i64 2)) > > > > llc fails an assertion: > > > > llc: /home/jdenny/llvm-svn/include/llvm/Support/Casting.h:202:

Hi again, So I finally gave up on trying to get through the converting (x86' push pop mov add) because it deals a lot with crazy pointer arithmetics and sonce inttoptr and ptrtoint doesn't provide any alias analysis information. Daniel, you said it doesn't make much sense to provide it but in my cases it is actually very much needed, you didn't say it wasn't possible to