similar to: Propagating noalias annotation

Hi, Alexandre, We don't have anything currently which does this. Note that, without further analysis of the uses of the potentially-noalias pointers, you can do this only for arguments with distinct (and identified) underlying objects (i.e., you need something a bit stronger than just "non-aliasing pointers"). -Hal On 11/16/2017 10:11 AM, via llvm-dev wrote: > Is this

On 11/17/2017 01:49 AM, Hongbin Zheng wrote: > Could you elaborate "Note that, without further analysis of the uses > of the potentially-noalias pointers, you can do this only ..."? > Why the uses, instead of the def, of pointer matter? Both matter. static int foo(int *a, int *b) { return a[0] + b[1]; } int bar(int *x) { return foo(x+1, x); } You can't mark a and

On 11/17/2017 02:01 AM, Hongbin Zheng wrote: > Do you mean a and b are noalias if: > > static int foo(int *a, int *b) { > return a[0] + b[0]; > } > > int bar(int *x) { > return foo(x+1, x); > } > > ? > > To me, because "AA.alias((x+1, MemoryLocation::UnknownSize), > (x, MemoryLocation::UnknownSize)) != NoAlias", so a and b are not noalias.

Hello fellow LLVM developers, I was wondering about the semantic of aliasing. Here are some examples where I am not sure if the two stores aliases: Example 1: for (int i = 2; i < n; ++i) { store A[i]; store A[i-2]; } Example 2: for (int i = 2; i < n; ++i) store A[i]; for (int i = 2; i < n; ++i) store A[i-2]; In the example 1, they do not alias in a single iteration, but they

And again... LLVM_BUILD_LLVM_DYLIB:BOOL=ON LLVM_LINK_LLVM_DYLIB:BOOL=ON This one is the good one... maybe. On Tue, Sep 6, 2016 at 11:35 PM, Alexandre Isoard < alexandre.isoard at gmail.com> wrote: > That is because I mistyped it: > LLVM_ENABLE_LLVM_DYLIB:BOOL=ON > LLVM_LINK_LLVM_DYLIB:BOOL=ON > > On Tue, Sep 6, 2016 at 11:31 PM, Wink Saville <wink at saville.com>

Note that there is a slight difficulty due to the fact that we "sink" the trunc: (zext i16 {0,+,1}<%bb> to i32) + (65536 * ({0,+,1}<nuw><%bb> /u 65536) Here the recurrence lost it's <nuw> and got reduced to a i16 (on the left), but not on the right. But we can prove: - that (zext i16 {0,+,1}<%bb> to i32) has the same 16 LSB than (i32

On 07/05/2017 03:10 PM, Alexandre Isoard wrote: > Ah, ok. I read it wrong. In *neither* case it is UB. > > Hum, can an implementation define it as UB? :-) Nope :-) The only case I've thought of where we could add these for C++ would be on conversions to (most) enums (because they used signed underlying types and the out-of-bounds mapping won't generally be one of the allowed

According to 6.3.1.3/3 of the C standard (I didn't check C++): "3 Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised." I *think* that means that IF a signal is raised then the signal raised could be one that you can't guarantee to be able to return from

On Tue, Sep 6, 2016 at 3:05 PM, Alexandre Isoard <alexandre.isoard at gmail.com> wrote: > LLVM_ENABLE_DYLIB Where/when/how do you specify LLVM_ENABLE_DYLIB and LLVM_LINK_DYLIB? I tried the following on the cmake command line: $ cmake -G Ninja .. -DCMAKE_INSTALL_PREFIX=/home/wink/opt/llvm -DLLVM_ENABLE_DYLIB=true -DLLVM_LINK_DYLIB=true And got: ... -- Performing Test

Hello, Yes? Where is allActive defined, I couldn't find it. Basically, a BB is control divergent if it's execution depends on a branch that itself depends on a divergent ssa value. On Fri, Jul 21, 2017 at 4:13 PM, Zaks, Ayal <ayal.zaks at intel.com> wrote: > What would be the definition of “isControlDivergent(BasicBlock*)”; the > complementary of “allActive(BasicBlock*)” –

Hi, Even if there are no ways in which a *frontend* can produce nsw truncs, it may still be useful to have if optimization passes can usefully attach nsw to truncates (after proving the truncates don't "overflow"). For instance in %a = ashr i64 %v, i32 33 %t = trunc %a to i32 the trunc can be marked nsw. However, the burden of proof here is to show that we can do some useful

I did not observe any assertion. In addition, the documentation ( https://llvm.org/docs/LangRef.html#undefined-values) says: The string ‘undef’ can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern. Undefined values may be of any type (other than ‘label’ or ‘ void’) and be used anywhere a constant is permitted. Either way,

On Wed, Jul 5, 2017 at 3:59 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 07/04/2017 01:41 AM, Dr.-Ing. Christoph Cullmann via llvm-dev wrote: > >> Hi, >> >> Hi Alexandre, >>> >>> LLVM currently doesn't have trunc nsw/nuw, no. >>> Which frontend would emit such instructions? Any application in mind?

Ok. To go back to the original issue, would it be meaningful to add a SCEVUMax(0, BTC) on the final BTC computed by SCEV? So that it does not use "negative values"? On Wed, Aug 15, 2018 at 2:40 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 2:27 PM, Alexandre Isoard wrote: > > I'm not sure I understand the poison/undef/UB distinctions. >

Hello, I assumed SCEV purpose was to be a normal form, but then I wondered which one of those is the normal form: (zext i16 (trunc i32 %a to i16) to i32) vs (-((%a /u 65536) *u 65536) + %a) The first one is nice for interval analysis, and known bit analysis. The second one is nice when plugged into gep of 2d arrays. -- *Alexandre Isoard* -------------- next part -------------- An HTML

On Wed, Aug 24, 2016 at 10:11 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 24 August 2016 at 08:48, Alexandre Isoard via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I am probably stating the obvious, but if the function is side-effect > free > > (onlyReadsMemory) it is valid to remove it. > > > > But I am guessing that does not

Good question. AFAIK, the IR-printer doesn’t understand the semantics of parameter attributes. In this case, it only knows that there is an attribute on the parameter that is integer valued (with value 1) and that has the name “align”, so it prints it out. If we don’t want it printing out ‘align 1’ then it’s up to us to not set the alignment parameter attribute to a value if that value would be 1.

Hi Alexandre, On Wed, Oct 19, 2016 at 11:19 AM, Alexandre Isoard <alexandre.isoard at gmail.com> wrote: > I am probably missing something important, but what I mean is that you can > always convert: > > %y = xor %x, %x > to > %y = 0 > > Regardless of if %x is/might be an undef. That is, consider that reading %x > any number of times always give the value of its

On Fri, Nov 3, 2017 at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 11/03/2017 07:20 PM, Alexandre Isoard via llvm-dev wrote: > > Hello, > > I am not sure about the semantic (if any) of returns_twice and noreturn > attributes. > > int fork() __attribute__((returns_twice)); > void join(int) __attribute__((noreturn)); > > int f(int n) { > int

I'm not sure I understand the poison/undef/UB distinctions. But on this example: define i32 @func(i1 zeroext %b, i32 %x, i32 %y) { > entry: > %adds = add nsw i32 %x, %y > %addu = add nuw i32 %x, %y > %cond = select i1 %b, i32 %adds, i32 %addu > ret i32 %cond > } It is important to not propagate the nsw/nuw between the two SCEV expressions (which unification would