[PATCH] Changing the Back-end when Target Options Change

[Bill Wendling]

Hi all!

This patch is the culmination of the attributes changes I did last year. It changes the back-end when target options change. For instance, if one function was compiled with the `-msoft-float' command line option and another was compiled without that flag, then we want functions to generate the correct code, even if their modules are merged.

So what does this patch do?

When the target options change, it regenerates the TargetMachine object. It does this using a placement-new method, because a reference to the TargetMachine object is stored in several places. So it's important to reuse the memory address. (The same is true for the TargetConfigPass object that the TargetMachine creates.)

Why do we need to regenerate the TargetMachine?

The back-end code was built around the assumption that once the TargetMachine object was generated, none of the state it built up would change. For instance, how instruction selection treats specific types may depend on the target options. It is a very long-term project to move to a system where the function's attributes are checked directly. That said, this isn't a "hack", but could be looked upon as an intermediate step from what we have to what would be ideal.

I ran some tests, and there doesn't appear to be a difference in compilation time for the normal case --- one where the module contains functions generated with the same command line options.

Please review this patch and submit your comments and flamage.

-bw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: changing-target-options.patch
Type: application/octet-stream
Size: 38006 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130605/dec0ecf8/attachment.obj>
-------------- next part --------------