On Oct 5, 2012, at 12:08 AM, Nick Lewycky <nicholas at mxc.ca> wrote:> I absolutely think that we should have something like TargetData (now DataLayout) but for the vector types and operations. However, I'm not familiar with "Target Lowering Interface". Could you explain?I agree. Once we make the codegen accessible to the IR-level passes we need to start talking about the right abstraction. I have some ideas, but I wanted to start the discussion after we are done with the first phase. Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use the TLI interface which can answer questions such as "is this operation supported ?" or "is this type legal". This is a subset of what we need in a vectorized. We can discuss other requirements that the vectorizer may have after we finish with the first phase. I suspect that we may have to refactor some functionality out of TLI.> > Currently TLI is only available in LLC. I suggest that we merge LLC and OPT into a single tool that will drive both IR-level passes and the codegen. > > This really shouldn't be necessary. Notably, it is still possible today to build a Module and optimize it without having decided what target you're targeting.I agree that it is not necessary for many optimizations. However, this is absolutely needed for lower-level transformations such as strength reduction. So, I plan to keep the current behavior that OPT has where if a target information is not provided through the command line then TargetData is kept uninitialized (null pointer). So, as far as IR-level passes go, nothing is going to change.> > Nick-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/cc918739/attachment.html>
> Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use the TLI > interface which can answer questions such as "is this operation supported ?" > or "is this type legal". This is a subset of what we need in a vectorized. > We can discuss other requirements that the vectorizer may have after we > finish with the first phase. I suspect that we may have to refactor some > functionality out of TLI. >Possibly, though I think TargetData should still be able to get you what you want.> > Currently TLI is only available in LLC. I suggest that we merge LLC and OPT > into a single tool that will drive both IR-level passes and the codegen. >*shrug* I really don't think this is necessary either. There's really no need for merging the two tools (and IMO would weaken the separation here). Why not just have TargetData/TargetLoweringInfo in opt?> I agree that it is not necessary for many optimizations. However, this is > absolutely needed for lower-level transformations such as strength > reduction. So, I plan to keep the current behavior that OPT has where if a > target information is not provided through the command line then TargetData > is kept uninitialized (null pointer). So, as far as IR-level passes go, > nothing is going to change. >TargetData is pretty useful during opt if it's available, probably no need to merge the tools though. -eric
----- Original Message -----> From: "Eric Christopher" <echristo at gmail.com> > To: "Nadav Rotem" <nrotem at apple.com> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 1:29:50 PM > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > > Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use > > the TLI > > interface which can answer questions such as "is this operation > > supported ?" > > or "is this type legal". This is a subset of what we need in a > > vectorized. > > We can discuss other requirements that the vectorizer may have > > after we > > finish with the first phase. I suspect that we may have to > > refactor some > > functionality out of TLI. > > > > Possibly, though I think TargetData should still be able to get you > what you want.I think this is the wrong way to look at the problem. The real question is: why should we keep OPT and LLC separate? Keeping them separate and using some extension of TargetData will just mean manually duplicating information in this extended TargetData that we otherwise have in the backends. This is error-prone [from personal experience] and otherwise unproductive. In addition, merging the tools will allow the consolidation of target-specific code in OPT. There is code in InstCombine, for example, that specifically deals with x86 intrinsics. This code should be moved into a callback provided by the x86 target. Currently, however, this is not possible because of this separation. -Hal> > > > > Currently TLI is only available in LLC. I suggest that we merge LLC > > and OPT > > into a single tool that will drive both IR-level passes and the > > codegen. > > > > *shrug* I really don't think this is necessary either. There's really > no need for > merging the two tools (and IMO would weaken the separation here). Why > not just have TargetData/TargetLoweringInfo in opt? > > > I agree that it is not necessary for many optimizations. However, > > this is > > absolutely needed for lower-level transformations such as strength > > reduction. So, I plan to keep the current behavior that OPT has > > where if a > > target information is not provided through the command line then > > TargetData > > is kept uninitialized (null pointer). So, as far as IR-level passes > > go, > > nothing is going to change. > > > > TargetData is pretty useful during opt if it's available, probably no > need to merge > the tools though. > > -eric > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
Nadav Rotem wrote:> > On Oct 5, 2012, at 12:08 AM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > >> I absolutely think that we should have something like TargetData (now >> DataLayout) but for the vector types and operations. However, I'm not >> familiar with "Target Lowering Interface". Could you explain? > > I agree. Once we make the codegen accessible to the IR-level passes we > need to start talking about the right abstraction. I have some ideas, > but I wanted to start the discussion after we are done with the first > phase. > > Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use the > TLI interface which can answer questions such as "is this operation > supported ?" or "is this type legal". This is a subset of what we need > in a vectorized. We can discuss other requirements that the vectorizer > may have after we finish with the first phase. I suspect that we may > have to refactor some functionality out of TLI.Okay, if you're referring to llvm::TargetLowering, then yes that should have a whole slew of methods copied out to a new object (I'm imagining TargetVectorData with a getter in TargetData) that would answer those questions. Exposing TargetLowering itself is a bad idea since its interface refers to MCExpr* and SDValue and other things that genuinely don't make sense at the IR level.>> Currently TLI is only available in LLC. I suggest that we merge LLC >> and OPT into a single tool that will drive both IR-level passes and >> the codegen. >> >> This really shouldn't be necessary. Notably, it is still possible >> today to build a Module and optimize it without having decided what >> target you're targeting. > > I agree that it is not necessary for many optimizations. However, this > is absolutely needed for lower-level transformations such as strength > reduction. So, I plan to keep the current behavior that OPT has where if > a target information is not provided through the command line then > TargetData is kept uninitialized (null pointer). So, as far as IR-level > passes go, nothing is going to change.How much do you like the way TargetData works? With the strings in the module? It has the benefit of having a working design which means you won't get much noise about it in review. The downside is that all the information that goes into the TargetVectorData would have to be be encoded as a string and put into the Module. You'll have to invent an encoding and write a parser for it. Yuck. The upside is that it preserves the IR / codegen distinction that we've all grown to love, and does it using a mechanism that is in LLVM terms as old as the hills. No reviewer could argue that. I was imagining a new "target vectorunit = "..."" string in the modules. If you want a different way of doing it for the vector information, I might ask that you change how TargetData works too. :) Nick
----- Original Message -----> From: "Nick Lewycky" <nicholas at mxc.ca> > To: "Nadav Rotem" <nrotem at apple.com> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 1:53:53 PM > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > Nadav Rotem wrote: > > > > On Oct 5, 2012, at 12:08 AM, Nick Lewycky <nicholas at mxc.ca > > <mailto:nicholas at mxc.ca>> wrote: > > > >> I absolutely think that we should have something like TargetData > >> (now > >> DataLayout) but for the vector types and operations. However, I'm > >> not > >> familiar with "Target Lowering Interface". Could you explain? > > > > I agree. Once we make the codegen accessible to the IR-level passes > > we > > need to start talking about the right abstraction. I have some > > ideas, > > but I wanted to start the discussion after we are done with the > > first > > phase. > > > > Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use > > the > > TLI interface which can answer questions such as "is this operation > > supported ?" or "is this type legal". This is a subset of what we > > need > > in a vectorized. We can discuss other requirements that the > > vectorizer > > may have after we finish with the first phase. I suspect that we > > may > > have to refactor some functionality out of TLI. > > Okay, if you're referring to llvm::TargetLowering, then yes that > should > have a whole slew of methods copied out to a new object (I'm > imagining > TargetVectorData with a getter in TargetData) that would answer those > questions. > > Exposing TargetLowering itself is a bad idea since its interface > refers > to MCExpr* and SDValue and other things that genuinely don't make > sense > at the IR level. > > >> Currently TLI is only available in LLC. I suggest that we merge > >> LLC > >> and OPT into a single tool that will drive both IR-level passes > >> and > >> the codegen. > >> > >> This really shouldn't be necessary. Notably, it is still possible > >> today to build a Module and optimize it without having decided > >> what > >> target you're targeting. > > > > I agree that it is not necessary for many optimizations. However, > > this > > is absolutely needed for lower-level transformations such as > > strength > > reduction. So, I plan to keep the current behavior that OPT has > > where if > > a target information is not provided through the command line then > > TargetData is kept uninitialized (null pointer). So, as far as > > IR-level > > passes go, nothing is going to change. > > How much do you like the way TargetData works? With the strings in > the > module? It has the benefit of having a working design which means you > won't get much noise about it in review. > > The downside is that all the information that goes into the > TargetVectorData would have to be be encoded as a string and put into > the Module. You'll have to invent an encoding and write a parser for > it. > Yuck.Furthermore, you might want something more powerful, or just more concise, than a static description. In some cases using code will be better, and so providing an API, IMHO, will be a superior solution. -Hal> > The upside is that it preserves the IR / codegen distinction that > we've > all grown to love, and does it using a mechanism that is in LLVM > terms > as old as the hills. No reviewer could argue that. > > I was imagining a new "target vectorunit = "..."" string in the > modules. > If you want a different way of doing it for the vector information, I > might ask that you change how TargetData works too. :) > > Nick > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
Hi Eric, On Oct 5, 2012, at 11:29 AM, Eric Christopher <echristo at gmail.com> wrote:>> Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use the TLI >> interface which can answer questions such as "is this operation supported ?" >> or "is this type legal". This is a subset of what we need in a vectorized. >> We can discuss other requirements that the vectorizer may have after we >> finish with the first phase. I suspect that we may have to refactor some >> functionality out of TLI. >> > > Possibly, though I think TargetData should still be able to get you > what you want.TargetData does not have enough information for vectorization. For example, we need to ask the target if it has efficient "cos4" implementation or the cost of 'mult_4xf32'. We need lots of target specific information for deciding when to vectorize and which vectorization optimizations to apply.> >> >> Currently TLI is only available in LLC. I suggest that we merge LLC and OPT >> into a single tool that will drive both IR-level passes and the codegen. >> > > *shrug* I really don't think this is necessary either. There's really > no need for > merging the two tools (and IMO would weaken the separation here). Why > not just have TargetData/TargetLoweringInfo in opt?If we want TLI in opt then we need to link it with the codegen. This makes OPT almost identical to LLC. IT will link with the same libraries and just differ in the command line arguments.> >> I agree that it is not necessary for many optimizations. However, this is >> absolutely needed for lower-level transformations such as strength >> reduction. So, I plan to keep the current behavior that OPT has where if a >> target information is not provided through the command line then TargetData >> is kept uninitialized (null pointer). So, as far as IR-level passes go, >> nothing is going to change. >> > > TargetData is pretty useful during opt if it's available, probably no > need to merge > the tools though.TargetData is useful, but not enough for vectorization.> > -eric
On Oct 5, 2012, at 11:53 AM, Nick Lewycky <nicholas at mxc.ca> wrote:> Nadav Rotem wrote: >> >> On Oct 5, 2012, at 12:08 AM, Nick Lewycky <nicholas at mxc.ca >> <mailto:nicholas at mxc.ca>> wrote: >> >>> I absolutely think that we should have something like TargetData (now >>> DataLayout) but for the vector types and operations. However, I'm not >>> familiar with "Target Lowering Interface". Could you explain? >> >> I agree. Once we make the codegen accessible to the IR-level passes we >> need to start talking about the right abstraction. I have some ideas, >> but I wanted to start the discussion after we are done with the first >> phase. >> >> Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use the >> TLI interface which can answer questions such as "is this operation >> supported ?" or "is this type legal". This is a subset of what we need >> in a vectorized. We can discuss other requirements that the vectorizer >> may have after we finish with the first phase. I suspect that we may >> have to refactor some functionality out of TLI. > > Okay, if you're referring to llvm::TargetLowering, then yes that should have a whole slew of methods copied out to a new object (I'm imagining TargetVectorData with a getter in TargetData) that would answer those questions.Yes.> Exposing TargetLowering itself is a bad idea since its interface refers to MCExpr* and SDValue and other things that genuinely don't make sense at the IR level.I think that I agree. I am still not sure what the right abstraction is. We'll have to discuss this in detail later on. Hopefully sooner than later.> >>> Currently TLI is only available in LLC. I suggest that we merge LLC >>> and OPT into a single tool that will drive both IR-level passes and >>> the codegen. >>> >>> This really shouldn't be necessary. Notably, it is still possible >>> today to build a Module and optimize it without having decided what >>> target you're targeting. >> >> I agree that it is not necessary for many optimizations. However, this >> is absolutely needed for lower-level transformations such as strength >> reduction. So, I plan to keep the current behavior that OPT has where if >> a target information is not provided through the command line then >> TargetData is kept uninitialized (null pointer). So, as far as IR-level >> passes go, nothing is going to change. > > How much do you like the way TargetData works? With the strings in the module? It has the benefit of having a working design which means you won't get much noise about it in review. >TargetVectorData will have lots of details. It will have a list of available library calls and a list of costs for every instruction that the ISA has. We can't serialize it. If anything, i predict that will look allot like TargetLibInfo, just generated with tablegen.> The downside is that all the information that goes into the TargetVectorData would have to be be encoded as a string and put into the Module. You'll have to invent an encoding and write a parser for it. Yuck.> The upside is that it preserves the IR / codegen distinction that we've all grown to love, and does it using a mechanism that is in LLVM terms as old as the hills. No reviewer could argue that. > > I was imagining a new "target vectorunit = "..."" string in the modules. If you want a different way of doing it for the vector information, I might ask that you change how TargetData works too. :) >Maybe. :)> Nick >