similar to: [LLVMdev] Correct usage of `llvm.assume` for loop vectorization alignment?

Adam, Please find the attached test case (run with ToT opt -O3). As you can see, `y_body` successfully is vectorized, though %33 and %46 are deemed MayAlias despite their exclusive use in loads ands stores marked with `llvm.mem.parallel_loop_access`. Many Thanks, Josh On Thu, Mar 19, 2015 at 12:55 PM, Adam Nemet <anemet at apple.com> wrote: > > > On Mar 19, 2015, at 9:43 AM,

Hi, Can any llvm pass change simple return branch into select/return pair? For example: define i10 @mod_N(i10 zeroext %a) zeroext { entry: %tmp2 = icmp ugt i10 %a, -400 ; <i1> [#uses=1] br i1 %tmp2, label %cond_true, label %return cond_true: ; preds = %entry %tmp5 = add i10 %a, 400 ; <i10> [#uses=1] ret i10 %tmp5 return: ; preds = %entry ret

[AMD Official Use Only - Internal Distribution Only] Hi , There seems to be some issue with attributor, exactly in File Attributor.cpp, Function Attributor::rewriteFunctionSignatures(), Line No: 1600 (approrimate). The llvm source code at above address is as follows: // Eliminate the instructions *after* we visited all of them. for (auto &CallSitePair : CallSitePairs) {

So, I'm not really sure if this is the right approach. I'd like some folks from the LLVM side of things to chime in. In general, I'm not certain we want to continue growing our dependence on the signext and zeroext attributes on return types, or whether we want to do the extension in the frontend instead. Most of the targets in Clang currently eagerly zext or sext the return value to

Hi Suresh, thanks for reporting this! I thought I fixed this with 8d94d3c3b44c3a27a69b153cef9be4b8e481150e. Did you run before or after that commit? Cheers, Johannes On 5/15/20 7:17 AM, Mani, Suresh via llvm-dev wrote: > [AMD Public Use] > > Hi , > > Please ignore the earlier header of Internal and Official use only. > > Thanks > M Suresh > > From: llvm-dev

Hi all, Consider this C code: #include <stdbool.h> bool func(int n1, int n2, bool b) { bool greater = n1 > n2; if (greater && b) { if (n1 == n2) { return false; // unreachable } } return true; } The line marked unreachable cannot be reached, however currently LLVM does not optimize it out. I believe this is because LLVM does not

In SelectionDAGBuilder::visitRet(), there is this bit of code: // FIXME: C calling convention requires the return type to be promoted // to at least 32-bit. But this is not necessary for non-C calling // conventions. The frontend should mark functions whose return values // require promoting with signext or zeroext attributes. if (ExtendKind !=

On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote: > Promoting the return value is unsafe for bool returns on x86-64, which in the latest revision of the ABI only guarantees that the top 7 bits of the 8-bit register are 0. My comment is a bit off, because the question of what type to make the return value is somewhat orthogonal to the question of which zext assert we should add. Cameron

Hi! We are compiling a very large C project in llvm and trying to execute it in interpreter. There is a problem with executing the generated bitcode. We are using lli.exe and llvm-gcc.exe from official 2.6 LLVM release. We have localized the problem to following c code: -------------------- int f(unsigned char x) __attribute__((noinline)); int f(unsigned char x) { return x - 1; } int main()

On Thu, Jun 30, 2016 at 6:09 PM, Carlos Liam via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > Consider this C code: > > #include <stdbool.h> > > bool func(int n1, int n2, bool b) { > bool greater = n1 > n2; > if (greater && b) { > if (n1 == n2) { > return false; // unreachable > } >

On Thu, Jun 30, 2016 at 6:45 PM, Daniel Berlin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Jun 30, 2016 at 6:09 PM, Carlos Liam via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> Consider this C code: >> >> #include <stdbool.h> >> >> bool func(int n1, int n2, bool b) { >>

On 22 October 2012 14:53, Chandler Carruth <chandlerc at google.com> wrote: > So, I'm not really sure if this is the right approach. I'd like some > folks from the LLVM side of things to chime in. > > In general, I'm not certain we want to continue growing our dependence > on the signext and zeroext attributes on return types, or whether we > want to do the

Hi All, Using clang+llvm at head, I noticed a weird behaviour with the following reduced testcase : $ cat test.c #include <stdint.h> struct R { uint16_t a; uint16_t b; }; volatile struct R * const addr = (volatile struct R *) 416; void test(uint16_t a) { struct R r = { a, 1 }; *addr = r; } $ clang -O2 -o - -emit-llvm -S -c test.c ; ModuleID = 'test.c' target

Hi All, In the language reference manual, the access behavior of the memcpy, memmove and memset intrinsics is not well defined with respect to the volatile flag. The LRM even states that "it is unwise to depend on it". This forces optimization passes to be conservatively correct and prevent optimizations. A very simple example of this is : $ cat test.c #include <stdint.h>

Hi all, In order to identify loops I'm using the DILexicalScope metadata attached to the loop latch, but with some combinations of optimisations that metadata seems to disappear. For example, when -simplifycfg removes a block because it only contains a branch, and -loop-simplify recreates that block because it turned out to be a back-edge of some loop, the metadata gets removed.

On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: > On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger > > The original issue is that clang maps restrict on function arguments to > > NoAlias and that makes compares against the address of global variables > > false. Minimal test case: > > > > @y = external global i32 > > > > define zeroext i1

On 22/10/12 21:12, Rafael Espíndola wrote: > On 22 October 2012 14:53, Chandler Carruth <chandlerc at google.com> wrote: >> So, I'm not really sure if this is the right approach. I'd like some >> folks from the LLVM side of things to chime in. >> >> In general, I'm not certain we want to continue growing our dependence >> on the signext and

PropagateEquality in gvn.cpp However, if you are going to do it, remember the goal is to make the code simpler and easier, not just pile on to the current mess to catch more cases :) On Mon, Jul 4, 2016, 7:51 AM Carlos Liam <carlos at aarzee.me> wrote: > Where would I look to change the equality propagation? > > > - CL > > On Jun 30, 2016, at 11:45 PM, Daniel Berlin

Kristaps Straupe wrote: > Hi! > > We are compiling a very large C project in llvm and trying to execute > it in interpreter. There is a problem with executing the generated > bitcode. The interpreter is under-maintained in general, but this bug in particular is fixed SVN as-of r86428. Are you on a platform that isn't supported by llvm's jit? Nick > We are using

When the IR specifies a 32 bit load can it be changed to a narrower load? What if the load is from memory (e.g. a peripheral) that only supports 32-bit access? Consider the following IR: ---- target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:32" target triple = "thumbv7m-unknown-unknown" @f = external global i32 define zeroext i8 @bar() nounwind { L.0: