Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Intrinsic's "Commutative" property"
2009 Apr 16
3
[LLVMdev] Help me improve two-address code
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.
>>
2013 Dec 23
2
[LLVMdev] Commutability of X86 FMA3 instructions.
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
2020 Mar 23
3
[InstCombine] Addrspacecast and GEP assumed commutative
I'm not sure what the usual "ping time" is for llvm-dev, but may I ask if there are any updates on this?
It appears that the following lines are the root cause of the reordering (https://github.com/llvm/llvm-project/blob/fdcb27105537f77c78c4473d4f7c47146ddbab69/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2175):
// Handle gep(bitcast x) and gep(gep x, 0, 0, 0).
Value
2019 Sep 10
2
tablegen exponential behavior
Hi,
I implemented a pattern matching of the dot product for arm64
and it seemed to work well for the basic case, i.e.,
class mulB<SDPatternOperator ldop> :
PatFrag<(ops node:$Rn, node:$Rm, node:$offset),
(mul (ldop (add node:$Rn, node:$offset)),
(ldop (add node:$Rm, node:$offset)))>;
class mulBz<SDPatternOperator ldop> :
PatFrag<(ops node:$Rn,
2013 Dec 20
2
[LLVMdev] Commutability of X86 FMA3 instructions.
Hi Kay,
My patch will partially address your bug. For now I'm just looking to
switch the default FMA from vfmadd213xx to vfmadd231xx. That will
cause the code in PR17229 to compile as desired, but would regress
code like:
double foo(double a, double b, double c) {
return a * b + c;
}
Which will now require a vmovaps + vfmadd231.
If this impacts real benchmarks we could add an
2019 Jun 11
3
How to tell LLVM to treat Commutable library calls as such, for example multiplication?
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
2009 Jul 06
2
[LLVMdev] Help on DAG pattern matching string
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
2012 Jan 14
0
[LLVMdev] TableGen: Avoid/Ignore the "no immediates on RHS of commutative node" constraint.
Ivan,
Sorry, no, I wasn't clear enough. Both "op dst_reg,immediate,src_reg" and
"op dst_reg,src_reg,immediate" are allowed in the ALU ops. For most
instructions these are two different things - e.g. sub a,5,b is different
from sub,a,b,5 obviously - but for things like add they just define the
same thing.
My problem is that LLVM won't allow immediates on the LHS of
2018 Nov 07
2
how to add a instruction
Hi,every one.
I' in trouble again.
I want add a new intrinsic mapping a new instruction.
I add the int_x86_max_qb as fllowing:
def int_x86_max_qb: GCCBuiltin<"__builtin_x86_max_qb">, Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], [Commutative]>;
BUILTIN(__builtin_x86_max_qb, "iii", "")
I define the intrinsic as Pseudo instruction,it
2012 Jan 14
0
[LLVMdev] TableGen: Avoid/Ignore the "no immediates on RHS of commutative node" constraint.
Dear all,
I was wondering if it is possible in TableGen to either:
1. Selectively define an instruction depending on an SDNode's properties,
e.g. if the SDNode is not commutative.
2. Override/ignore the TableGen error given when a commutative node has an
immediate on the LHS.
My case comes from trying to define a generic ALU operation multiclass for
my target, which includes a
2009 Dec 07
2
[LLVMdev] How to use property 'isCommutable' in target description file?
Hi everyone,
I practice writing target description file with MSP430 reference.
I add a multiply-and-add instruction as below:
let isTwoAddress=1 in {
def MULADD:Pseudo<(out GR16:$dst), (ins GR16:$src1, GR16:$src2,
GR16:$src3),
"muladd\t{$dst, $src2, $src3}",
[(set GR16:$dst, (add GR16:$src1, (mul
GR16:$src2,
2009 Dec 08
1
[LLVMdev] How to use property 'isCommutable' in target description file?
Thanks to Anton.
Frankly said i don't know the exact meaning and purpose of 'isCommutable'.
By my opinion "add.w r6, r7" != "add.w r7, r6", so we shouldn't set
isCommutable = 1.
Who would like give an example to demonstrate what benifit it has if
'isCommuatble=1' in instruction selection, register allocation or other
process?
Regards
2009/12/7,
2009 Jun 26
0
[LLVMdev] bitwise AND selector node not commutative?
On Jun 25, 2009, at 4:38 PM, David Goodwin wrote:
> Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b)
> have similar patterns, as we would expect:
>
> defm t2BIC : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not node:
> $RHS))>>;
> defm t2ORN : T2I_bin_irs<"orn", BinOpFrag<(or node:$LHS, (not node:
>
2009 Jun 26
1
[LLVMdev] bitwise AND selector node not commutative?
On Jun 25, 2009, at 6:06 PM, Evan Cheng wrote:
>
> On Jun 25, 2009, at 4:38 PM, David Goodwin wrote:
>
>> Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b)
>> have similar patterns, as we would expect:
>>
>> defm t2BIC : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not
>> node:$RHS))>>;
>> defm t2ORN :
2009 Jun 25
2
[LLVMdev] bitwise AND selector node not commutative?
Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b)
have similar patterns, as we would expect:
defm t2BIC : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not node:
$RHS))>>;
defm t2ORN : T2I_bin_irs<"orn", BinOpFrag<(or node:$LHS, (not node:
$RHS))>>;
Compiling the following three works as expected:
%tmp1 = xor i32
2009 Jun 26
1
[LLVMdev] "icmp eq", "icmp ne" not commuting operands on ARM
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
2008 Oct 08
3
[LLVMdev] Lost instcombine opportunity: "or"s of "icmp"s (commutability)
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
2005 Mar 01
2
[LLVMdev] SparcV9 branches
Hi,
I need to generate a branch instruction from within
CodeGenIntrinsic in SparcV9BurgISel.cpp. I generate a few
instructions and add them to the mvec vector, and then I need
to generate a branch whose target is the first instruction in
the vector.
I've seen how other portions of the code do this, but they
have access to more information than CodeGenIntrinsic.
Thanks,
Brent
2020 Mar 24
2
[InstCombine] Addrspacecast and GEP assumed commutative
It appears that this behaviour of InstCombine is at least somewhat intended, as there are several tests that fail after the change mentioned before: cast.ll, gep-addrspace.ll and getelementptr.ll in test/Transforms/InstCombine.
I feel a little uncomfortable applying the patch after knowing this, and removing those tests doesn't seem like a great solution.
What are your thoughts?
For now, I
2008 Oct 08
0
[LLVMdev] [PATCH] Lost instcombine opportunity: "or"s of "icmp"s (commutability)
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