[LLVMdev] sign extensions, SCEVs, and wrap flags

Duncan Sands baldrick at free.fr
Thu Sep 20 01:28:11 PDT 2012


>     Sorry, I probably led you astray. No-self-wrap is useful for determining
>     trip count, but does not mean that sign/zero extension can be hoisted.
>     But if you run your analysis after -indvars, the sign-extension should be
>     removed if possible. The algorithm walks the derived induction variables
>     specifically looking for add nsw/nuw and replacing only those IR users with
>     a wide induction variable. See GetExtendedOperandRecurrence.
>     If you have a situation where the sign extends cannot removed, then you may
>     need your own IR-level analysis to determine whether you can ignore them.
>     Otherwise, you may run into trouble operating on SCEVs that contain
>     sext/zext/truncs. Are all your array indices uniformly sign-extended? I
>     don't know if this is a good idea, but why can't you consider the sext
>     operand the array index rather than the gep operand? If you prove that the
>     narrow indices are disjoint, then the extended indices must be disjoint.
>     SCEV operations should work fine on the narrow indices which shouldn't have
>     any impure type casting operations.
>     This can all be avoided by limiting your optimization to code that uses
>     pointer-size loop counters!
>     -Andy
> The array indices are out of my control; depends on the code people write. If
> they'd use long ints for everything, life would be good; but ints happen.

I thought array indices were promoted to a larger size when possible...  This
came up with Ada where loops with i8 counters are quite common.  Dan added
logic to boost the size of the loop counters, but perhaps it doesn't promote
them beyond i32, or doesn't apply here for some reason?

Ciao, Duncan.

> I'll play with -indvars.
> Thanks,
> Preston
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list