On Wed, 8 Apr 2020 at 04:23, Kai Wang <kai.wang at sifive.com> wrote:> If we apply the type system pointed out by Renato, is the vector type <vscale x 1 x i16> legal? If we decide that <vscale x 1 x i16> is a fundamentally impossible type, does it contrary to the philosophy of LLVM IR as reasonably target-independent IR? I do not get the point of your argument.Hi Kai, Don't worry about target-independent IR in your design of intermediate passes or lowering. By the time the front-end lowers to LLVM IR, it already has, often irreversible, target-specific knowledge in it. If by some stroke of luck that doesn't happen, then using "<vscale x anything>" is enough indication that you should not try to lower that onto a target that it wasn't specifically aimed at. No one expects the middle-end to be target-neutral. That's the whole point of constantly asking target-specific machinery (like TTI) about what's possible or what's "good" and what's not. More importantly, the closer you are to the end of the pass pipeline, the closer the IR is to machine IR. It's not uncommon, and often expected, to see "just the right amount of shuffles" to match lowering patterns into MIR and then Asm. IIRC, OpenCL or some other parallel-compute/graphic oriented pipeline does use odd vector shapes and legalise them later on. I may be severely outdated in my opinion, and happy to be corrected, but I don't think it would be totally egregious to carry on with (whole numbered) vector shapes that aren't strictly legal, as long as you guarantee that *any* such pattern gets correctly legalised by the lowering. If you can make the adversarial cases performing on top of that, it's a bonus, not a target. Hope this helps. cheers, --renato
Hi Renato, Thanks for your reply. IIUC. If I could lower LLVM IR to Asm correctly under my type system design, there should be no problem with it. Another concern I have is that llvm.vscale intrinsic is designed to return integer value. Should we relax it to return float or something else? Thanks. Kai On Wed, Apr 8, 2020 at 5:36 PM Renato Golin <rengolin at gmail.com> wrote:> On Wed, 8 Apr 2020 at 04:23, Kai Wang <kai.wang at sifive.com> wrote: > > If we apply the type system pointed out by Renato, is the vector type > <vscale x 1 x i16> legal? If we decide that <vscale x 1 x i16> is a > fundamentally impossible type, does it contrary to the philosophy of LLVM > IR as reasonably target-independent IR? I do not get the point of your > argument. > > Hi Kai, > > Don't worry about target-independent IR in your design of intermediate > passes or lowering. > > By the time the front-end lowers to LLVM IR, it already has, often > irreversible, target-specific knowledge in it. > > If by some stroke of luck that doesn't happen, then using "<vscale x > anything>" is enough indication that you should not try to lower that > onto a target that it wasn't specifically aimed at. > > No one expects the middle-end to be target-neutral. That's the whole > point of constantly asking target-specific machinery (like TTI) about > what's possible or what's "good" and what's not. > > More importantly, the closer you are to the end of the pass pipeline, > the closer the IR is to machine IR. It's not uncommon, and often > expected, to see "just the right amount of shuffles" to match lowering > patterns into MIR and then Asm. > > IIRC, OpenCL or some other parallel-compute/graphic oriented pipeline > does use odd vector shapes and legalise them later on. > > I may be severely outdated in my opinion, and happy to be corrected, > but I don't think it would be totally egregious to carry on with > (whole numbered) vector shapes that aren't strictly legal, as long as > you guarantee that *any* such pattern gets correctly legalised by the > lowering. > > If you can make the adversarial cases performing on top of that, it's > a bonus, not a target. > > Hope this helps. > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200411/38be2c89/attachment.html>
Hi Kai, On Sat, 11 Apr 2020 at 15:55, Kai Wang <kai.wang at sifive.com> wrote:> IIUC. If I could lower LLVM IR to Asm correctly under my type system design, there should be no problem with it.It depends on what you mean by "no problem". :) The design of the IR is target independent, so that we can represent language constructs in a generic way and optimise them with a common infrastructure. However, there are three main sources of target-dependence: 1. Front-ends may lower different IR depending on different targets, for example valid types, call ABI, etc. 2. The middle-end takes decisions based on target validity, which changes the shape of IR, for example specific sequences of instructions on specific types. 3. Intrinsic functions. Those can be generated by the front-end or a pass optimises code with them, for example, the vectoriser. The general trend is that the IR becomes more target-dependent as more passes change it, but it also means passes are less and less able to recognise patterns and therefore are less useful on your code. That's why pass ordering matters. A good example is GPU/accelerator code, that if you pass the IR through the normal pipeline, it comes out the other way unrecognisable and impossible to lower, so they tend to have their own pass pipelines. You don't want to have a special, so you need to make sure your IR is as generic as possible, or you won't profit as much, or worse, will break apart. More specifically, the entirety of vscale design has been assuming integral scales, so anything that is not integral will very likely not work with existing (and future) standard passes. By making your target more special, you have also made it harder to optimise. Neither you nor the rest of the community wants to add special cases for odd targets in every optimisation pass, so we need to find a common ground.> Another concern I have is that llvm.vscale intrinsic is designed to return integer value. Should we relax it to return float or something else?I personally believe that this would open a can of worms we don't want to handle. Not right now, at the very least. I would strongly oppose to a float value, for all of the problems FP representation has and the expectation of existing instructions of taking integer values. But it could be doable to have a fractional value, like two integers, where the numerator doesn't have to be greater than nor a multiple of the denominator (with default value as 1). Again, I'm not the authority here, I'm just giving some context. Other scalable vector developers should chime in with their opinion. cheers, --renato