[LLVMdev] llvm-gcc promotes i32 mul to i64 inside __muldi3
Sergey Yakoushkin
sergey.yakoushkin at gmail.com
Thu Mar 18 05:34:32 PDT 2010
Hi,
LLVM mis-compiles soft int64 mul '__muldi3' (either libgcc or
compiler-rt) unless some specific efforts are taken in the back-end to
custom lower i64 operations back to i32.
Issue appears also in CellSPU/Alpha, and there exist workarounds which
use custom lowering to vector instructions.
My case is different.
Deeply embedded processors have optional multiplier unit (e.g.
disabled at design time). Thus, efficient and compact MUL
implementation is not available, i32 mul is implemented as __mulsi3 in
libgcc.
Seems retargetable back-end requires additional efforts in this case:
either to rewrite __muldi3 source code to avoid mul promotion or to
custom lower i64 mul.
Am I missing someting?
Does this problem affects existing back-ends like PIC16?
Could you please help with some hints. How to implement mul i64
lowering to mul i32 (which must be replaced with __mulsi3)? are there
any examples in existing back-ends?
Thanks,
Sergey Y.
2010/3/18 Sergey Yakoushkin <sergey.yakoushkin at gmail.com>:
>> This shouldn't be necessary, IMO. If you were going to implement it,
>> then the correct thing to do would be to have generic selection dag
>> lowering of large multiplies, which renders the library mostly
>> useless.
> In fact, I would prefer to avoid custom lowering for operations on large types.
> i64 will be rare in my case (embedded) and their performance is not an issue.
> I need basic i64 support only for functional correctness.
>
>> Any soft int stuff that lowering hasn't already implemented.
> Taking into account known issues with soft int staff...
> Why expansion of large MULs/etc into smaller ones is not default
> behavior of ExpandNode (LegalizeDAG)?
> (seems meaningful if i32 operation is Legal or Custom)
> Are there any plans to add that?
>
> Regards,
> Sergey Y.
>
More information about the llvm-dev
mailing list