[llvm] r184175 - Use pointers to the MCAsmInfo and MCRegInfo.

[Bill Wendling]

On Jun 18, 2013, at 11:13 AM, David Blaikie <dblaikie at gmail.com> wrote:

> On Tue, Jun 18, 2013 at 12:20 AM, Bill Wendling <isanbard at gmail.com> wrote:
>> Author: void
>> Date: Tue Jun 18 02:20:20 2013
>> New Revision: 184175
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=184175&view=rev
>> Log:
>> Use pointers to the MCAsmInfo and MCRegInfo.
>> 
>> Someone may want to do something crazy, like replace these objects if they
>> change or something.
> 
> Reasonable people may disagree, but for myself I'd rather we keep
> references wherever possible (eg: in parameters where there's no
> intention to support null values) & only use pointers where we need to
> be able to re-point the value. (honestly, if I were being pedantic,
> I'd prefer to write a non-nullable non-owning pointer of a sort (can
> only be assigned from a value/reference, not a pointer) to document
> that these things can't be null - a concern I have whenever I see a
> pointer)
> 
I make no claims of being reasonable :-), but I do agree with you. However, there are two reasons why I wanted to do this. The first being what I briefly described above (allowing the values to change). The second being this horrible piece of code:

In lib/CodeGen/MachineModuleInfo.cpp:

MachineModuleInfo::MachineModuleInfo()
  : ImmutablePass(ID),
    Context(*(MCAsmInfo*)0, *(MCRegisterInfo*)0, (MCObjectFileInfo*)0) {
  llvm_unreachable("This MachineModuleInfo constructor should never be called, "
                   "MMI should always be explicitly constructed by "
                   "LLVMTargetMachine");


Blech!

I wrote about what I would like to do before, but I think it's time to revisit it. Basically, what I'd like to do is somehow regenerate the back-end --- or at least the important bits of the back-end --- when and if target-dependent options change between functions. This is important for LTO, and is the last step of my attribute rewrite work. The problem with regenerating the back-end is that it has been built under the assumption that once all of the important objects have been created, they no longer change. So many parts of the back-end cache various objects at various times. If these objects now change, the cached values are no longer valid, etc. 

The natural question now is: why would I want to regenerate the back-end? Isn't it enough to have them directly query the attributes during the back-end's execution and modify the behavior that way?

Yes and no. If you look at the TargetOption object, several of those values directly affect how different objects are initialized. For example, the ISel lowering code changes how different types are handled based on this information. Some changes have cascading effects. In short, it becomes very messy very quickly, and it's easy to miss something. The ideal situation would be that the back-end queries the attributes for everything it needs. But this isn't feasible at this time. And I believe it will be a very large effort to move the back-end towards this goal. And to be honest, after looking at the back-end, I'm not sure how successfully we can reach that goal.

If you like, you can think of regenerating the back-end as an intermediate step. Once it's finished and LTO is working correctly, we can incrementally change the back-end so that not everything needs to be regenerated.

-bw