similar to: [LLVMdev] Problem recognizing nested select operations

On Mon, Sep 30, 2019 at 11:52 AM Joan Lluch <joan.lluch at icloud.com> wrote: > > Hi Roman, > > Is "test" actually an implementation of a 64-bit-wide multiplication > compiler-rt builtin? > Then i'd think the main problem is that it is being optimized in the > first place, you could end up with endless recursion… > > > No, this is not a compiler-rt

On Sun, Sep 29, 2019 at 3:35 PM Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sanjay, > > Actually, the CodeGenPrepare::optimizeSelectInst is not doing the best it could do in some circumstances: The case of “OptSize" for targets not supporting Select was already mentioned to be detrimental. > > For targets that actually have selects, but branches

For the MSP430 example, I'm guess its InstCombiner::transformSExtICmp or InstCombiner::transformZExtICmp ~Craig On Mon, Sep 30, 2019 at 2:21 PM Support IMAP <support at sweetwilliamsl.com> wrote: > Hi all, > > Ok, I just found a much simpler example of the same issue. > > Consider the following code > > int cmpge32_0(long a) { > return a>=0; > } >

Hi, I am just found a scalar evolution function that does not seem canonical to me. The C code I used to produce it is: long foo (long n, long m) { long i, j; long A[n][m]; for (i = 0; i < n; ++i) for (j = 0; j < m; ++j) A[i][j] = 1; return A[42][42]; } This produces after applying -mem2reg the attached LLVM-IR. For the store to the array A in the loop I get

Hi Sanjay, Thanks for your reply. > So yes, the IR optimizer (instcombine is the specific pass) sometimes turns icmp (and select) sequences into ALU ops. Instcombine is almost entirely *target-independent* and should remain that way. The (sometimes unfortunate) decision to create shifts were made based on popular targets of the time (PowerPC and/or x86), and other targets may have suffered

On 27 October 2010 14:20, Tobias Grosser <grosser at fim.uni-passau.de> wrote: > Hi, > > I am just found a scalar evolution function that does not seem canonical to > me. > > The C code I used to produce it is: > > long foo (long n, long m) { > long i, j; > long A[n][m]; > > for (i = 0; i < n; ++i) > for (j = 0; j < m; ++j) >

Hi everyone, I'm having some trouble with my ifelse statements. I'm trying to put 12 conditions within 3 groups. Here is the code I have so far: dat$cond <- ifelse(test = dat$cond == "cond1" | dat$cond == "cond2" | dat$cond == "cond3" dat$cond == "cond4" yes = "Uniform" no = ifelse(test =

Changing the order of the checks in CodeGenPrepare::optimizeSelectInst() sounds good to me. But you may need to go further for optimum performance. For example, we may be canonicalizing math/logic IR patterns into 'select' such as in the recent: https://reviews.llvm.org/D67799 So if you want those to become ALU ops again rather than branches, then you need to do the transform later in

Hi! I've have Instruction in my code: ... %call6 = call i32 %9(%class.A* %call3, i32 2) ... And I want to get something like this: ... %11 = icmp eq i32 (%class.D*, i32)* %10, @_ZThn4_N1D1xEi br i1 %11, label %12, label %14 ; <label>:12 ; preds = %7 %13 = bitcast %class.A* %call3 to %class.D* %call64 = call i32

Is there a transformation in LLVM that will perform loop fusion? http://en.wikipedia.org/wiki/Loop_fusion I have the following program, in which I would like the 2 loops (iterating the same number of times) to be merged into 1, after which other nice optimizations such as mem2reg will apply: ; ModuleID = 'test' define void @vector([16 x float]* nocapture %arg, [16 x float]* nocapture

Hi, InstCombine canonicalizes index operands (unless they are into struct types) to pointer size. The comment says: "If we are using a wider index than needed for this platform, shrink it to what we need. If narrower, sign-extend it to what we need. This explicit cast can make subsequent optimizations more obvious.". For our architecture, the canonicalization is a bit

Hello to everybody, I'm working on some improvements on trip count computation with ScalarEvolution analysis. Considering the following test ;----------------------------------------------------------------------------; define void @foo(i32 %a, i32 %b, i32 %s) #0 { entry: %cmp = icmp sgt i32 %s, 0 %cmp15 = icmp sgt i32 %a, %b %or.cond = and i1 %cmp, %cmp15 br i1 %or.cond, label

LLVM seems to be generating way too complex of branching based on the short-circuit optimization. The code in question is as follows: define void @ test_fc_while_and(float %x, float %y, float addrspace(11)* %result) nounwind { entry: %tobool3 = fcmp une float %x, 0.000000e+000 ; <i1> [#uses=1] %tobool24 = fcmp une float %y, 0.000000e+000 ;

I am investigating changing BoundsChecking to use address-based rather than size- & offset-based tests. To explain, here is a short code sample cribbed from one of the tests: %mem = tail call i8* @calloc(i64 1, i64 %elements) %memobj = bitcast i8* %mem to i64* %ptr = getelementptr inbounds i64* %memobj, i64 %index %4 = load i64* %ptr, align 8 Currently, the IR for bounds checking

On Oct 1, 2013, at 6:45 AM, Michele Scandale <michele.scandale at gmail.com> wrote: > Hello to everybody, > > I'm working on some improvements on trip count computation with ScalarEvolution > analysis. > Considering the following test > > ;----------------------------------------------------------------------------; > define void @foo(i32 %a, i32 %b, i32 %s) #0

Codeprepare and independent blocks are introducing these loads and stores. These are prepasses that polly runs prior to building the dependence graph to transform scalar dependences into data dependences. Ether was working on eliminating the rewrite of scalar dependences. On Thu, Aug 15, 2013 at 5:32 AM, Star Tan <tanmx_star at yeah.net> wrote: > Hi all, > > I have investigated the

Hello, I'd like to offer an alternative solution to the "poison problem": remove it. What follows is rather informal. I'd happily write up a nicer document if this RFC stands up to scrutiny. The idea was born from two observations: - undef was introduced to model a load of uninitialized memory, a form of undefined behavior. - poison was introduced to model integer overflow,

Hi Sebpop, Thanks for your explanation. I noticed that Polly would finally run the SROA pass to transform these load/store instructions into scalar operations. Is it possible to run such a pass before polly-dependence analysis? Star Tan At 2013-08-15 21:12:53,"Sebastian Pop" <sebpop at gmail.com> wrote: >Codeprepare and independent blocks are introducing these loads and

I do not think that running SROA before polly is a good idea: it would defeat the purpose of the code preparation passes that polly intentionally schedules for the data dependence analysis. If you remove the data references before polly runs, you would miss them in the dependence graph: that could lead to incorrect transforms. On Thu, Aug 15, 2013 at 7:28 PM, Star Tan <tanmx_star at

Hi Kevin, Thanks for your interest and for your deep analysis. Unfortunately, your approach doesn't catch all bugs and is vulnerable to an attack. Consider the following case: ...................... | ----- obj --- | | end ^ ptr ^ ^ end-of-memory The scenario is as follows: - an object is allocated in the last page of the address space - obj is byte