[LLVMdev] [RFC] CGContext skeleton implementation

[Andrew Trick]

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

> 
> On Thu, Dec 5, 2013 at 5:04 PM, Andrew Trick <atrick at apple.com> wrote:
> Right. On the flip side, some passes should be able to make hard queries against target/subtarget that fail if the driver doesn’t initialize them. I don’t want any way to accidentally run the vectorizer or LSR without initializing my subtarget info. Also, I want to prevent early passes from getting at subtarget info.
> 
> <snip>
> 
> Passes that depend on TargetMachine can use CGContext for hard target and subtarget info queries. Since they must depend on TargetMachine anyway, they can do something like TM.getCGContext(Function).
> 
> This sounds like you want IR-level passes which have direct, hard dependencies on the target and codegen. That would be a radical departure from the core design of the IR / MI separation.

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.

Either way, we need an IR-level API that requires subtarget initialization. It should be explicit which passes do and don’t require the subtarget. This would add *a lot* of clarity to the role of CodeGenPrepare-style IR passes which is starting to become very murky. It would separate the problem of providing TargetMachine to IR passes from the problem of initializing the PassManager. The distinction between opt and llc passes has already become meaningless.

Back to this..

> LLVMContext
>   -> TargetContext (initialized when TargetMachine is available)
>     -> SubtargetContext (initialized when Function attributes are available)
> 
> Only if TargetContext and SubtargetContext are abstract interfaces with trivial implementations available for cases where there is no target (in the libTarget sense).


Yes, they could be abstract interfaces, but no, they wouldn’t have trivial implementations. TargetContext could be wrapped with trivial implementations as a separate interface purely as a convenience for passes that use TargetContext “only if available” (effectively the current TTI). I would not want a wrapper for SubtargetContext.

> We have discussed this directly in the past and Chris and others have argued *very strongly* against this. If you want to reverse this design direction, it really should be a totally separate discussion from the current discussion. I'm not actually in the "strongly against" camp on this subject, but I *am* strongly against trying to design CGContext to address these needs when we don't yet have either a concrete design or agreement on that design. I think we should restrain our design considerations to what we need to solve the limited problem we have today, and not *breaking* the existing design around TTI, and the IR/Target layering we currently use.

The design problem we have today is that TTI and TargetMachine are broken in the presence of function attributes. And IR passes are using both TTI and TargetMachine directly. My first suggestion was a straightforward fix, but builds more layers of complexity:

IR Transform
(links with)   -> TargetTransformInfo
(dynamic call) -> X86TTI
(links with)   -> TargetMachine
(provides)     -> CGContext

(IR passes that use TargetMachine directly would need to be fixed to use CGContext).

I like Dan’s suggestion of using LLVMContext as the container instead, but we have to think about how that fits with existing TTI—when should a pass use one or the other? I suggest that passes that use target info *if available* continue using TTI while lowering passes directly use CG/SubtargetContext.

I’m not aware that what I’ve suggested contradicts any previous discussions. There have been lengthy discussions on whether we should extend LLVM IR to support more lowering in IR passes. I agree with Chris and others that we should *not* extend LLVM IR to support lowering. That’s a separate issue.

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