Expose target-specific pre-linking passes in TargetMachine

[yaxunl]

Summary

Sometimes a backend needs to apply certain target-specific passes before linking. These passes sit in target directory and Clang needs a way to access them.

This patch attempts to expose target-specific pre-linking passes by adding a virtual member function addPreLinkPasses to TargetMachine.

The link to the discussion in cfe-dev about pre-linking passes is here:

http://lists.llvm.org/pipermail/cfe-dev/2016-May/048822.html

The related Clang change is here:

http://reviews.llvm.org/D20681

[yaxunl]

Ping

Chandler, could you please take a look? Thanks.

[yaxunl]

Remove unnecessary argument.

[yaxunl]

Daniel, Christopher, Mehdi,

Sorry to add you as my reviewers without asking first. Would you please review my patch if you get time? Thanks.

[mehdi_amini]

(general comment: upload patches with full context please)

include/llvm/Target/TargetMachine.h

259

The comment is not very useful, it basically repeats the function name and would still let me puzzled.

I read the thread on cfe-dev, but I'm still don't really sure to understand where it would be called, do you have the clang patch ready?

[mehdi_amini]

include/llvm/Target/TargetMachine.h

259

Just saw the link to the clang patch in the description....

[chandlerc]

I fundamentally do not believe that the TargetMachine should be involved in fixing language semantics issues with a "pre linking" pass at the LLVM level. Why? Because there is nothing "target" about this.

There needs to be a fundamentally more principled way of handling this at the language and frontend level IMO.

[Anastasia]

In D20682#457117, @chandlerc wrote:

I fundamentally do not believe that the TargetMachine should be involved in fixing language semantics issues with a "pre linking" pass at the LLVM level. Why? Because there is nothing "target" about this.

There needs to be a fundamentally more principled way of handling this at the language and frontend level IMO.

I personally don't think adding more target specific details to frontend is a good idea from the point of view of modular design.

It would be nice to understand why you think that this is not target enough for this purpose.

[echristo]

I've read the cfe-dev summary and I'm still not sure why you need this - what's going on here?

-eric

[yaxunl]

In D20682#457939, @echristo wrote:

I've read the cfe-dev summary and I'm still not sure why you need this - what's going on here?

-eric

Basically some OpenCL builtin functions are not easily implemented by library only. Instead, they need to be transformed by some pre-linking passes then linked with the library. These passes are target specific, so they need to stay in the specific target directory. Then we need a way to tell Clang that we want these passes before linking with libraries for this target.

[mehdi_amini]

How is it "target specific" (in the backend sense) and not "toolchains" or "platform" specific?

Also "PreLinking" is really not a great choice (and the two patches could benefit from a lot more documentation) as linking is usually what happens when the compiler is done.

include/llvm/Target/TargetMachine.h

     return true;
   }
 
+  /// Add target-specific pre-linking passes to the specified pass manager.
+  virtual void addPreLinkPasses(PassManagerBase &, raw_pwrite_stream &) {}
+
   /// True if subtarget inserts the final scheduling pass on its own.
   ///
   /// Branch relaxation, which must happen after block placement, can