llvm dev - Dec 2013 - [LLVMdev] [RFC] CGContext skeleton implementation

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. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131205/c368f207/attachment.html>

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>

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 -- 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.


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.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131205/e3c3bfe0/attachment.html>