[LLVMdev] proposed change to class BasicTTI and dual mode mips16/32 working

[reed kotler]

On 03/28/2013 12:22 PM, Nadav Rotem wrote:
> Hi Reed,
>
> On Mar 28, 2013, at 12:18 PM, Reed Kotler <rkotler at mips.com 
> <mailto:rkotler at mips.com>> wrote:
>
>> As for the BasicTransformInfoPassass, for this dual mode I'm using 
>> createNoTargetTransformInfoPass right now.
>
> So, MIPS does not need LSR, LowerSwitch and other optimizations that 
> depend on TTI ?
>
As an experiment, I built a flavor of llvm inside of Mips that always 
uses createNoTargetTransformInfoPass and it passed make check and ran 
all of test-suite with no problems for Mips32.

This is not a realistic long term solution but the functionality works 
at least.
>> I will solve this issue of the BasicTransformInfoPass being immutable 
>> after this initial checking which gets all the functionality. I was 
>> able to make in a function pass but ran into some issues so I put that
>> aside for now.
>>
>
> IMHO the right way to handle target function attributes is to 
> re-initialize the target machine and TTI for every function (if the 
> attributes changed).  Do you have another solution in mind ?
>
I agree. I need to study that code more to have some ideas as to how to 
do this.
Maybe you or Bill Wendling know exactly how to do this. If you guys want 
to work on that I can leave it alone or else I'll probably start to work 
on it after I push what I have thus far. I will probably
push my changes sometime next week after more testing and cleanup.

I will be putting this createNoTargetTransformationInfoPass on a mips 
specific switch for now.

In gcc, they actually have an option which compiles every other function 
as either mips16 or nomips16 as a way to test this on a large source 
base. I will probably add that option.

My solution to all of this was surprisingly simple after I got a good 
handle on this problem.
It would work for ARM and ARM thumb easily. It's not a very big patch 
but I went through many
iterations and was able to eliminate all target independent parts of the 
patch in that way.

> Thanks,
> Nadav

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/ced02da1/attachment.html>