llvm dev - Mar 2013 - [LLVMdev] proposed change to class BasicTTI and dual mode mips16/32 working

So I have dual mode 16/32 compilation on a per function basis working.

I need to clean up some things and then will push the change.

I managed to do everything without needing to change anything in target 
independent code thus far. It was a fun puzzle to solve as to how to do 
this using only the given APIs.

As for the BasicTransformInfoPassass, for this dual mode I'm using 
createNoTargetTransformInfoPass right now.

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.

The basic problem was to be able to compile:

void __attribute__((mips16)) foo (void) {

}


void __attribute__((nomips16)) nofoo (void) {

}

So first function is compiled as mips16 and the second as mips32.

Thanks to Bill Wendling for all this new attribute work he did which 
allowed me to just focus on the exact problem in hand.


On 03/22/2013 03:22 PM, Nadav Rotem wrote:
> Hi Reed,
>
> We will need to reconstruct the target machine and the TTI chain when
> the function attributes change. We currently don't have code for doing
> that but I suggest that you talk with Bill Wendling about the best way
> to implement this.
>
> Thanks,
> Nadav
>
> On Mar 22, 2013, at 11:30 AM, Reed Kotler <rkotler at mips.com
> <mailto:rkotler at mips.com>> wrote:
>
>> Just realized that BasicTransformInfoClass is an immutable pass.
>>
>> Not sure how to reconcile this with fact that there will be different
>> answers needed depending on the subtarget.
>>
>> Seems like BasicTansformInfoClass should become a function pass that
>> does not modify  anything.
>>
>> On 03/22/2013 09:43 AM, Reed Kotler wrote:
>>> Another way to do this would to be to have a reset virtual function
>>> which is passed the Function, and the address of TLI so that it
could be
>>> modified.
>>>
>>> This seems somewhat cleaner.
>>>
>>> The reset virtual function would be added to base class
>>> TargetLoweringBase.
>>>
>>>
>>> On 03/22/2013 09:22 AM, reed kotler wrote:
>>>> For being able to change subtargets within a compilation unit,
among
>>>> other things, I need to be able to change the target lowering
class that
>>>> is used by BasicTTI
>>>>
>>>> For example we have a mips16 and non mips16 version.
>>>>
>>>> On the original call that creates this class, I'd like to
pass the
>>>> address of the address of the TargetLoweringBase class.
>>>>
>>>> That way I can insert a function pass before this pass which
examines
>>>> the function attributes and changes the pointer.
>>>>
>>>> So we would get:
>>>>
>>>> ImmutablePass *
>>>> llvm::createBasicTargetTransformInfoPass(const
TargetLoweringBase
>>>> **TLI_) {
>>>>   return new BasicTTI(TLI);
>>>> }
>>>>
>>>> we would add the variable
>>>>
>>>> TargetLoweringBase **TLI_
>>>>
>>>> and at the beginning of each pass
>>>>
>>>> TLI = *TLI_;
>>>>
>>>> Maybe there is a more elegant way to do this but this is
essentially
>>>> what I need to do.
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Hi Reed, 

On Mar 28, 2013, at 12:18 PM, Reed Kotler <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 ?
> 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 ?

Thanks,
Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/4a0b76b1/attachment.html>

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>

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote:
> 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 don't really understand this.

TargetMachine and TTI may be quite expensive to initialize. Doing so for
each (sometimes tiny) function processed doesn't make a lot of sense to me.

Wouldn't it be better to design a TargetMachine (and TTI, or other passes
that are similar) which provides context-sensitive answers? You could
imagine this being a wrapper which delegates to one of two real TM and TTI
implementations based on a mode switch.

Alternatively, we could look at partitioning functions into two modules,
and then bring up the infrastructure once per module.

I would personally choose between these based on how much shared
functionality there would be in the TM and TTI between the two.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130401/a71389c1/attachment.html>