similar to: [LLVMdev] Status of pre-legalize vector changes

On Mon, 11 Jun 2007, Dan Gohman wrote: > Here's a quick update on where I'm at with the pre-legalize vector changes > I'm working on. I hope to have an updated patch ready to a few days, assuming > I don't get too busy with other projects going on. Here are some of the issues > I've come across so far. Great! I'm going to reorder your email a bit to suit my

On Mon, Jun 11, 2007 at 03:39:40PM -0700, Chris Lattner wrote: > On Mon, 11 Jun 2007, Dan Gohman wrote: > > Also, CopyToReg and CopyFromReg lowering/legalization rely on being able to > > create vector-of-vector types. For example, an <8 x double> vector is bitcasted > > to (effectively) <4 x <2 x double>> for x86, allowing EXTRACT_ELEMENT to pull > >

After doing a bunch of work for moving pre-legalize extended ValueTypes into a table in SelectionDAG, I may have just found a simpler approach. There are under 32 simple ValueType values, so we only really need 5 bits to represent those. ValueType is already a 32-bit type on most hosts; what if we make use of the remaining 27 bits instead of using an external table? If we can assume that vector

Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at

Right now there are special SelectionDAG node kinds for operations on "abstract" vector types (VLOAD, VADD, and all the rest), and a special MVT::Vector ValueType for them. These nodes carry two additional operands, constants which specify the vector length and element type. All of this is only used before legalize; then they are replaced with regular node kinds and value types. It

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

On Jun 22, 2007, at 11:06 AM, Dan Gohman wrote: > After doing a bunch of work for moving pre-legalize extended > ValueTypes > into a table in SelectionDAG, I may have just found a simpler > approach. > > There are under 32 simple ValueType values, so we only really need > 5 bits > to represent those. ValueType is already a 32-bit type on most > hosts; what >

On Mon, Sep 29, 2008 at 8:11 PM, Mon Ping Wang <wangmp at apple.com> wrote: > The problem with generating insert and extracts is that we can generate poor > code > %tmp16 = extractelement <4 x float> %f4b, i32 0 > %f8a = insertelement <8 x float> %f8a, float %tmp16, i32 0 > %tmp18 = extractelement <4 x float> %f4b, i32 1 > %f8c

Hello, Working on my (currently out-of-tree) BG/Q PPC enhancements, I've run into the following problem with vector type legalization. Here's a quick example: Scalarize node result 0: 0x2348420: v1f32 = extract_subvector 0x23434a0, 0x2348320 [ID=0] Scalarize node result 0: 0x2348220: v1f32 = extract_subvector 0x23434a0, 0x23466e0 [ID=0] Split node result: 0x23469e0: v4f32 =

Richard Pennington wrote: > My target doesn't support 64 bit arithmetic, so I'd like to supply > definitions for adde/addc. The problem is I can't seem to figure out the > magic. Here's an example of what I need to generate: > > # two i64s in r5/r6 and r7/r8 > # result in r1/r2, carry in r3 > > # adde > add r2, r6, r8 > cmpltu r3, r2, r6 #

Hi, The current definition of shuffle vector is <result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <n x i32> <mask> ; yields <n x <ty>> The first two operands of a 'shufflevector' instruction are vectors with types that match each other and types that match the result of the instruction. The third

My target doesn't support 64 bit arithmetic, so I'd like to supply definitions for adde/addc. The problem is I can't seem to figure out the magic. Here's an example of what I need to generate: # two i64s in r5/r6 and r7/r8 # result in r1/r2, carry in r3 # adde add r2, r6, r8 cmpltu r3, r2, r6 # compute carry # addc add r1, r5, r7 add r1, zero, r3 Is this

Hi Sean, I had to add ‘v16f16’ to our out-of-tree target, and this was to primarily to allow me to express lowering for all the OpenCL types (well, except for the ‘v3T’ types). The trend does seem to be towards larger bit-width SIMD registers, and as you say this will increase in time; but perhaps instead of using a discrete enumeration combined with additional entries in several

Hi Hal, On 05/03/13 18:50, Hal Finkel wrote: > Hello, > > Working on my (currently out-of-tree) BG/Q PPC enhancements, I've run into the following problem with vector type legalization. Here's a quick example: > > Scalarize node result 0: 0x2348420: v1f32 = extract_subvector 0x23434a0, 0x2348320 [ID=0] > > Scalarize node result 0: 0x2348220: v1f32 = extract_subvector

Hi, Our backend for Pixel Visual Core uses some MVT's that aren't upstream. Does it make sense to upstream them? I figure that as architectures get wider, we'll eventually have "all" possible combinations of widths and types, but on the other hand having code that isn't used by current backends in tree isn't great. These are the MVT's that we have added: 16x16

Hi Krzysztof, Sure, please see below. DAG.dump.() before and after, annotated with what I believe the DAG means. I've spent some time debugging the method but it's proving difficult to determine where the logic is misfiring. Disabling the entire combine causes a lot of failing x86-64 tests - I may have to learn an upstream vector ISA to make progress on this. Thank you >From your

All the sub methods called inside ExpandIntegerOperand like ExpandInOp_STORE etc have access to the expanded operands map. Why they aren't passed to target LowerOperation? A target may also want to use the already expanded Lo and Hi parts. - Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

I'm curious about the design rationale for how ManagedStatic instances are cleaned up, and I'm hoping someone can shed some light on it. Currently, ManagedStatic objects are cleaned up when llvm_shutdown() traverses the global list of initialized objects and calls destroy() on each. This leads to two questions: 1. An assertion enforces that the objects are deleted in reverse order of

Right, I'm suggesting we keep llvm_shutdown() for users who want this control, but also destroy still-live ManagedStatic instances if llvm_shutdown() is not called. This helps in the case where there is not a clear time when llvm_shutdown() can be called, especially given that LLVM cannot be resurrected in the same process due to current limitations in the pass registry, and perhaps