[LLVMdev] IR passes depend on TargetMachine too (was [RFC] CGContext skeleton implementation)

[Andrew Trick]

On Dec 5, 2013, at 7:50 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> On Thu, Dec 5, 2013 at 7:36 PM, Andrew Trick <atrick at apple.com> wrote:
> It might nice if scalaropts did not need to link against libTarget—we could easily avoid introducing more dependence on libTarget if that’s a goal.
> 
> We already have that state today in the overwhelming majority of the cases. The pass manager built by the PassManagerBuilder doesn't need a target at all. Yes, there is CodeGenPrepare which violates all manner of rules, but thus far it has been viewed as a hack, and something that should go away because, at a very fundamental level, it *is* a lowering pass.
>  
> Either way, we need an IR-level API that requires subtarget initialization.
> 
> Why? The only concrete use case I can come up with is lowering, but you claim that you aren't trying to do lowering in the IR

Really?
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/63921

> -- If you can't make reasonable decisions without a concrete subtarget, then I claim you *are* lowering. This is why I suggested that this would be a very significant change in design from the direction that LLVM is currently moving.

What term would you like to use for "irreversible machine specific IR transformations”? We can call it destructive anti-canonicalization if you like :) The LLVM community is pushing in the direction of more machine specific IR transformations (both reversible and irreversible). I want to allow those to run later in the pipeline for better testing and maintenance. I want to see the framework formalized a bit so it’s easier for contributors to get things done the right way.

This has nothing to do with lowering to machine instructions. We do not want to model individual machine instructions and their side-effects with LLVM IR. We just want to produce the IR patterns that make sense for the microarchitecture.

> I can see the need for target *heuristics* in an optimization pass (not necessarily canonicalization) that is not doing lowering. But by definition of being heuristics, there is an obvious way to implement and test them in a target independent manner. When the target information is no longer a heuristic and cannot be stubbed out in a target independent manner, I claim that the transformation it is guiding has ceased to be target independent as well and doesn't belong in the IR.

That's not a useful or practical criteria for what should be implemented in IR. If target support is missing, IR optimization will be skipped and codegen will do terrible things. Not only is that uninteresting for testing, but I want to make sure it doesn’t accidentally happen as a result of driver hacking or untested combination of driver options.

The criteria for IR vs MI seems obvious. Can your transform be expressed in terms of IR operations, does it depend on ISEL choices, precise register pressure, instruction latency, or does it have a phase ordering dependence on an MI pass? IR is sometimes the better way to go for development time, simplicity, maintainability, and sharing across targets.

CodeGenPrepare doesn’t need to go away, it needs to be a collection of passes, some of which are completely target specific. 

I will say that one potential issue with target specific IR passes is how CodeGen currently uses AliasAnalysis, which somewhat assumes a canonical IR form.

> But all of this should absolutely be discussed in a separate thread (or in person) as it is largely orthogonal to allowing the TargetMachine to react appropriately to function attributes.


I tried to present possibilities for allowing TargetMachine to react to function attributes in the bulk of my message (the part that you didn’t quote). Hopefully Dan will choose an implementation that works for IR passes. We could continue discussing it in the original thread.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131205/d4011658/attachment.html>