llvm dev - Mar 2010 - [LLVMdev] llvm-gcc promotes i32 mul to i64 inside __muldi3

On Wed, Mar 17, 2010 at 4:57 PM, Sergey Yakoushkin
<sergey.yakoushkin at gmail.com> wrote:
> Thanks, yes, I'm facing the same issue.
>
> Hm... seems there are no simple fixes.
> I have to do one more i64 mul implementation to workaround aggressive
> optimizations.
> Is that correct? Is this the only way?
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.
> Can I disable only one particular pass which does this promotion from
> i32 to i64 using some LLVM-GCC option?
Not easily as far as I know.
> Are there other libgcc functions affected by this optimization?
Any soft int stuff that lowering hasn't already implemented.

Andrew

> 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.

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.
>