llvm dev - Mar 2015 - [LLVMdev] API Changes: TargetMachine::getSubtarget

Hi all,

As of r232885 I've removed the argument-less TargetMachine::getSubtarget
and TargetMachine::getSubtargetImpl. For the targets that aren't completely
independent of this I've gone ahead and left a non-virtual version of the
function in the target specific TargetMachine. What this means in practice
is that those targets can only use a bare getSubtarget call in their target
specific code, and should probably clean that up as soon as they can.
They'll definitely be unable to use any of the function multiversioning
support when it goes in and they'll be unable to LTO binaries that have
functions with different subtarget features/cpus.

Updating out of tree ports should be fairly straightforward for now.
Updating out of tree code otherwise should be ok, but given I've been
removing this stuff for some time you've probably been working on it
anyways. Do file bugs if there's anything I've missed or send me a
message
if you run into a problem (I know of a couple off hand that need
investigating).

Thanks!

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150321/66130b83/attachment.html>

On Fri, Mar 20, 2015 at 9:35 PM, Eric Christopher <echristo at gmail.com>
wrote:
> Hi all,
>
> As of r232885 I've removed the argument-less
TargetMachine::getSubtarget
> and TargetMachine::getSubtargetImpl.
>
Congrats!

> For the targets that aren't completely independent of this I've
gone ahead
> and left a non-virtual version of the function in the target specific
> TargetMachine. What this means in practice is that those targets can only
> use a bare getSubtarget call in their target specific code, and should
> probably clean that up as soon as they can. They'll definitely be
unable to
> use any of the function multiversioning support when it goes in and
they'll
> be unable to LTO binaries that have functions with different subtarget
> features/cpus.
>
> Updating out of tree ports should be fairly straightforward for now.
> Updating out of tree code otherwise should be ok, but given I've been
> removing this stuff for some time you've probably been working on it
> anyways. Do file bugs if there's anything I've missed or send me a
message
> if you run into a problem (I know of a couple off hand that need
> investigating).
>
> Thanks!
>
> -eric
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150320/157f71be/attachment.html>

On Fri, Mar 20, 2015 at 9:35 PM, Eric Christopher <echristo at gmail.com>
wrote:
> Hi all,
>
> As of r232885 I've removed the argument-less
TargetMachine::getSubtarget
> and TargetMachine::getSubtargetImpl. For the targets that aren't
completely
> independent of this I've gone ahead and left a non-virtual version of
the
> function in the target specific TargetMachine. What this means in practice
> is that those targets can only use a bare getSubtarget call in their target
> specific code, and should probably clean that up as soon as they can.
> They'll definitely be unable to use any of the function multiversioning
> support when it goes in and they'll be unable to LTO binaries that have
> functions with different subtarget features/cpus.
>
>
Thanks!

> Updating out of tree ports should be fairly straightforward for now.
> Updating out of tree code otherwise should be ok, but given I've been
> removing this stuff for some time you've probably been working on it
> anyways. Do file bugs if there's anything I've missed or send me a
message
> if you run into a problem (I know of a couple off hand that need
> investigating).
>
>
I noticed LLVMTargetMachine::addPassesToEmitFile is passing the default
MCSubtargetInfo to createMCInstPrinter. Since there are cases where
AArch64's InstPrinter looks at the target cpu to print an operand (see
AArch64SysReg::SysRegMapper::toString, which is called from
AArch64InstPrinter::printMRSSystemRegister), should we make changes in
AArch64AsmPrinter to pass down the per-function subtarget? You can compile
the attached IR with llc and see it doesn't output cyclone's system
register unless "-mcpu cyclone" is specified on the command line, even
thought the IR has "target-cpu"="cyclone" on the function. I
don't think
this affects correctness, but I thought I should point out the difference.


Thanks!
>
> -eric
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150323/3aa6ce79/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: instrprinter1.ll
Type: application/octet-stream
Size: 587 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150323/3aa6ce79/attachment.obj>

On Mon, Mar 23, 2015 at 3:54 PM Akira Hatanaka <ahatanak at gmail.com>
wrote:
> On Fri, Mar 20, 2015 at 9:35 PM, Eric Christopher <echristo at
gmail.com>
> wrote:
>
>> Hi all,
>>
>> As of r232885 I've removed the argument-less
TargetMachine::getSubtarget
>> and TargetMachine::getSubtargetImpl. For the targets that aren't
completely
>> independent of this I've gone ahead and left a non-virtual version
of the
>> function in the target specific TargetMachine. What this means in
practice
>> is that those targets can only use a bare getSubtarget call in their
target
>> specific code, and should probably clean that up as soon as they can.
>> They'll definitely be unable to use any of the function
multiversioning
>> support when it goes in and they'll be unable to LTO binaries that
have
>> functions with different subtarget features/cpus.
>>
>>
> Thanks!
>
>
>> Updating out of tree ports should be fairly straightforward for now.
>> Updating out of tree code otherwise should be ok, but given I've
been
>> removing this stuff for some time you've probably been working on
it
>> anyways. Do file bugs if there's anything I've missed or send
me a message
>> if you run into a problem (I know of a couple off hand that need
>> investigating).
>>
>>
> I noticed LLVMTargetMachine::addPassesToEmitFile is passing the default
> MCSubtargetInfo to createMCInstPrinter. Since there are cases where
> AArch64's InstPrinter looks at the target cpu to print an operand (see
> AArch64SysReg::SysRegMapper::toString, which is called from
> AArch64InstPrinter::printMRSSystemRegister), should we make changes in
> AArch64AsmPrinter to pass down the per-function subtarget? You can compile
> the attached IR with llc and see it doesn't output cyclone's system
> register unless "-mcpu cyclone" is specified on the command line,
even
> thought the IR has "target-cpu"="cyclone" on the
function. I don't think
> this affects correctness, but I thought I should point out the difference.
>
>
Yep. ARM is in a similar state and well, as I said in the followup to the
commit that added it:

"I hope it's temporary, but rewriting more huge swaths of the target
infrastructure in both the TargetStreamer (mips) and/or the AsmPrinter
which does this exact thing for a very similar reason is less on
correctness and more on API level. Fixing this inside both of those is
going to take some major reworking that may involve fairly significant
internal API changes. So, we workaround for the moment so we can ensure the
middle end code generation is clean and go from there."

I really don't want to talk about ARM's use. It's mostly that
keeping the
middle end clean was getting to be annoying and this temporary hack is a
decent workaround.

Basically it's going to be a lot of churn to fix it and I was already in
the middle of breaking lots of out of tree things so I figured I'd save it
for another week :)

-eric

>
> Thanks!
>>
>> -eric
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150323/f68019a4/attachment.html>