similar to: [LLVMdev] Order of operations

On Mar 25, 2008, at 8:32 PM, Jonathan S. Shapiro wrote: > Given variables a b c d of compatible scalar arithmetic types, > consider > the expression: > > a + b + c + d > > There are multiple implementation orders for computing this sum, and > the > one you want can be dependent on the source language specification. In > particular, the + operation must not be

On Tue, 2008-03-25 at 20:42 -0700, Chris Lattner wrote: > LLVM IR is three address code, not a tree form. This requires the > front-end to pick an ordering that works for it explicitly as it > lowers to LLVM IR. I got that much. But I assume that optimization passes, if used, are entitled to rewrite the IR. For example: ANSI C requires that certain types of parenthesization be

Hi, All, Duncan, Rafael, David, Nick. This is regarding pattern matching in InstructionCombine pass. We use 'match' functions many times, but it doesn't do the pattern matching effectively. e.x. Lets take pattern : (A ^ B) | ((B ^ C) ^ A) -> (A ^ B) | C (B ^ A) | ((B ^ C) ^ A) -> (A ^ B) | C Both the patterns above are same, since ^ is commutative in Op0. But,

Evan Cheng wrote: > On Apr 16, 2009, at 3:17 PM, Greg McGary wrote: > >> Is there some optimizer knob I'm not turning properly? In more complex >> cases, GCC does poorly with two-address operand choices and so bloats >> the code with unnecessary register moves. I have high hopes LLVM >> can do better, so this result for a simple case is bothersome. >>

> Hi Scott, > > Do you mean loop carried dependencies? There is some initial work on > dependence analysis, but it is still pretty young. We also have support for > dependence between memory operations that are not loop aware. > > -Chris I think the dependence analysis will have to be loop aware. For example: bb: %indvar = phi i64 [ 0, %bb.nph ], [ %indvar.next,

On Mar 25, 2008, at 8:57 PM, Jonathan S. Shapiro wrote: > On Tue, 2008-03-25 at 20:42 -0700, Chris Lattner wrote: > >> LLVM IR is three address code, not a tree form. This requires the >> front-end to pick an ordering that works for it explicitly as it >> lowers to LLVM IR. > > I got that much. But I assume that optimization passes, if used, are > entitled to

A few library calls are commutable by definition, for example multiplications. I defined them as LibCalls for my architecture. However, I found that arguments are always passed in the order they are generated by Clang thus missing possible optimisations. For example, the following IR code ; Function Attrs: minsize norecurse nounwind optsize readnone define dso_local i16 @multTest(i16 %a, i16

Hi, What does it mean when "Commutative" property is applied to an intrinsic with more than two arguments? For example, __builtin_ia32_dppd has this property. Thanks. -- Simon

On Wed, 2008-03-26 at 23:48 +0100, Óscar Fuentes wrote: > "Jonathan S. Shapiro" <shap at eros-os.com> writes: > My front-end is very similar to yours in the feature of the multiple > instantiations on demand, etc. Oscar: after you have a chance to read my recent reply to Gordon, would you be kind enough to let me know whether you still believe the situations are similar.

The SCEV framework sorts operands of commutative SCEVs by their getSCEVType() value, and then does an ad-hoc sort to group repeated operands, but it does not do a full sort. In some test cases I'm looking at right now, this causes it to miss opportunities to reuse SCEV objects, as in cases like this: ( %i + %r54 + %r59) ( %r54 + %r59 + %i) As a result, passes like LoopStrengthReduce

Hi Bill, Yes, there are other patterns. I tried commenting out all the other instructions definitions and I still get this error. After debugging TblGen I found that the second pattern is being generated as a variant of the first. I think the reason is that the PADD instruction is inheriting the commutative property from ADD defined inTargetSelectionDAG.td. The variant ends up being the same

NE and EQ comparisons should be able to commute their operands. But, for ARM at least, this does not seem to be happening. The first sequence below generates CMN (compare negated) but the second does not (complete test attached). These seem to map to ARMcmpNZ. Where would I look to see if that is marked commutative? %nb = sub i32 0, %b %tmp = icmp ne i32 %a, %nb %nb = sub

Hello everyone, I am trying to implement the max PTX builtin function. This is defined in the following way: "max.type d, a, b;" where .type can be: .type = { .u16, .u32, .u64, .s16, .s32, .s64 }; The presence of multiple types requires llvm.ptx.max to be overloaded for i16, i32 and i64. So I think that the right way to define the intrinsic would be (as in the

Hi guys. Check this out: > NaN +NA [1] NaN > NA + NaN [1] NA I thought "+" was commutative by definition. What's going on? > R.version _ platform powerpc-apple-darwin6.8 arch powerpc os darwin6.8 system powerpc, darwin6.8 status major 1 minor 9.0 year 2004 month 04 day 12 language R > (Both give NA under linux, so it looks

Hi Elena, Thank you very much for looking in to that. I'll go ahead and remove the isCommutable flag from those instructions, since it sounds like that's the right thing to do. I would still like to change the default from the 231 variant to 213 too, as this will reduce code-size for accumulator-style loops. I have at least one benchmark that shows significant speedups when this change

GCC for AVR is awesome but, as far as I know, until very little time ago, compiler support for PIC was close to none. 2008/5/19 Jonathan S. Shapiro <shap at eros-os.com>: > I have a client who might well make use of an AVR32 port, but I suspect > that machine is very different than the one you are currently examining. > > > shap > On Mon, 2008-05-19 at 12:38 -0600, John

"Jonathan S. Shapiro" <shap at eros-os.com> writes: [snip] > 4. Is there a better/cleaner approach? What other options should I > consider? My front-end is very similar to yours in the feature of the multiple instantiations on demand, etc. One thing I learnt about LLVM is that it's philosophy is to be a friendly backend for frontends, but whatever your frontend

Here's an initial stab, but I'm not too happy about the temporarily adding new instructions then removing it because returning it will have it added back in to replace other uses. I also added a couple test cases pass with the new InstructionCombining changes (the old code only passes one of the added tests). Also, this change exposes some simplification for

instcombine can handle certain orders of "icmp"s that are "or"ed together: x != 5 OR x > 10 OR x == 8 becomes.. x != 5 OR x == 8 becomes.. x != 5 However, a different ordering prevents the simplification: x == 8 OR x > 10 OR x != 5 becomes.. %or.eq8.gt10 OR x != 5 and that can't be simplified because we now have an "or" OR "icmp". What would I

I have a client who might well make use of an AVR32 port, but I suspect that machine is very different than the one you are currently examining. shap On Mon, 2008-05-19 at 12:38 -0600, John Regehr wrote: > Anyone else interested in an AVR backend? > > If so, for what members of the AVR family? If we do a port, likely it'll > support only the ATmegas. > > John >