[LLVMdev] IndVarSimplify too aggressive ?

Rotem, Nadav nadav.rotem at intel.com
Sun Mar 13 21:42:36 PDT 2011


Arnaud, 

I also noticed that IndVarSimplify increases variable size, and in some cases pessimize the program. I just wanted to add that I have seen cases where i64 types were converted to i65 types, for which there is no native support. In the case of i65 multiplication, for some platforms there is not even a library call to perform a 128bit multiplication. So, I welcome your change and I will test your patch locally. 

Nadav

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Arnaud Allard de Grandmaison
Sent: Sunday, March 13, 2011 23:02
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] IndVarSimplify too aggressive ?

Hi all,

The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one for several embedded targets, with very few native types.

I attached a patch to address this issue; if TargetData is available, the patch attempts to keep the induction variable to a native type when going thru the induction variable users.

Also attached my test-case in C, as well as the resulting assembly output, with and without the patch applied, for arm and x86_32 targets. You will note the loop instructions count can be reduced by 30% in several cases.

The patch could probably be made smarter : I am welcoming all suggestions.

Best Regards,
--
Arnaud de Grandmaison
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.





More information about the llvm-dev mailing list