[LLVMdev] proposed change to class BasicTTI and dual mode mips16/32 working
rkotler at mips.com
Thu Mar 28 12:40:42 PDT 2013
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
>> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev