Displaying 3 results from an estimated 3 matches for "xmul_lohi".
Did you mean:
umul_lohi
2010 Sep 09
2
[LLVMdev] Possible missed optimization? 2.0
>>Note that the isCommutable flag is only really useful for two-address
instructions. If the two inputs are not constrained, nothing is really won
by swapping them.
Ahh i see, good to know that.
>> Does the -view-*-dags output look correct?
They do look correct, there are three Xmul_lohi blocks, one returns the low
part copied into R14 and the rest of combinations get added and merged into
R15.
Here is my selectionDAG code, i used X86's MUL code and adapted it to my
target:
case ISD::SMUL_LOHI:
case ISD::UMUL_LOHI:
{
SDValue Op1 = N->getOperand(...
2010 Sep 09
0
[LLVMdev] Possible missed optimization? 2.0
On Sep 9, 2010, at 12:59 PM, Borja Ferrer wrote:
> Hello, i've noticed a new possible missed optimization while testing more trivial code.
> This time it's not a with a xor but with a multiplication instruction and the example is little bit more involved.
>
> C code:
>
> typedef short t;
> t foo(t a, t b)
> {
> t a4 = a*b;
> return a4;
> }
>
2010 Sep 09
2
[LLVMdev] Possible missed optimization? 2.0
Hello, i've noticed a new possible missed optimization while testing more
trivial code.
This time it's not a with a xor but with a multiplication instruction and
the example is little bit more involved.
C code:
typedef short t;
t foo(t a, t b)
{
t a4 = a*b;
return a4;
}
argument "a" is passed in R15:R14, argument "b" in R13:R12, the return value
is stored in