similar to: [LLVMdev] Question of function setOperationAction

Hi Alex, So far, the code you've mentioned only defines a couple tablegen classes but doesn't define the instruction itself. To define the instruction you will also need a 'def' statement. For MIPS MSA, this statement looks like this: def LD_D: LD_D_ENC, LD_D_DESC; This defines an instruction (LD_D) with the encoding specified by the LD_D_ENC class, and the operation

Thanks, indeed it was on the LegalizeDAG.cpp and the information proved very useful. I also realized that the customization, promotion or expansion will occur whenever any operand, with the same type as the type specified on the second argument (MVT) of setOperationAction function, appears. (Correct me if I'm wrong). The second doubt I have regards instruction matching. When I define a

On Mon, Jun 6, 2016 at 8:32 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > It is not a keyword. It is a node defined in > include/llvm/Target/TargetSelectionDAG.td. You can likely find most of the > definitions you're wondering about there. > In terms of its purpose, perhaps someone can elaborate on that a bit more, > but there is no corresponding

On 10/3/06, Roman Levenstein <romixlev at yahoo.com> wrote: > Hi, > > Few more questions that I found while trying to develop a new backend. > And sorry if I ask too many questions. I only have answers to some of them: > 1) My target (embedded processor, which is a "not so direct" successor > of Z80 family of processors) does not support SELECT, so I was looking

Hi Rafael, Thanks for the answers. > > 1) My target (embedded processor, which is a "not so direct" > successor > > of Z80 family of processors) does not support SELECT, so I was > looking > > for a workaround. > > > > First I was thinking about expanding it into conditional flow with > > branching, but then I have found that there exists a

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > 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

When LLVM does a comparison of two vectors, in this case with 16 elements, the returned type of setcc is v16i1. The architecture I'm targeting allows storing the result of a vector comparison as a bit mask in a scalar register, but I'm having trouble converting the result of setcc into a value that is usable there. For example, if I try to AND together masks that are the results of two

Sorry, glad I'm in the right place. Before I start, I want to state that I'm a beginer and I'm trying to develop a backend by adapting an existent target to my platform. My first doubt is about the SelectionDAG and the TargetLowering class. When I use, for example: setOperationAction(ISD::ADD, MVT::i1, Promote); Is it correct to say that I'm promoting any operand used by the

Hi Sebastian, On 22/05/2012 23:25, Sebastian Pop wrote: > Hi Eli, > > On Thu, Mar 1, 2012 at 2:21 PM, Eli Friedman<eli.friedman at gmail.com> wrote: >> On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum<tlinth at codeaurora.org> wrote: >>> Hey folks, >>> >>> We are having some difficulty with how we have been representing our >>>

If v4i8 is a legal type then getTypeToPromoteTo should return the pair v4i8 and 'legal'. This looks like the root of the problem. -----Original Message----- From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Monday, July 30, 2012 22:10 To: Rotem, Nadav; Developers Mailing List Subject: RE: Vector promotion broken for <2 x [i8|i16]> v4i8 itself is a legal type, just not

Hi Eli, On Thu, Mar 1, 2012 at 2:21 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum <tlinth at codeaurora.org> wrote: >> Hey folks, >> >> We are having some difficulty with how we have been representing our >> predicate registers, and wanted some advice from the list.  First, we >> had been

On Wed, 26 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > I am trying to lower all llvm operations to 8-bit. So far I was trying > to have llvm do all that for me using things like: ok > setOperationAction(ISD::ADD, MVT::ii,Promote); > setOperationAction(ISD::ADD, MVT::i8,Legal); > setOperationAction(ISD::ADD, MVT::i16,Expand); > setOperationAction(ISD::ADD,

On Thu, Sep 6, 2012 at 10:02 AM, Reed Kotler <rkotler at mips.com> wrote: > Here is the problem explained more. > > Normally there is a 64 bit register that is the result of certain multiply > and divide instructions. > It's really 2 32 bit registers. > > This is like HI[0]/Lo[0] > > In fact there are four such pairs, only the 0th pair available to basic >

Hi Guys, I noticed that the operation actions( promote/expand/custom) are set per operation basis. Wondering if we can set it up globally? For example, I have native supported 32 bits registers, to handle 8 bits value operations, I want to do promote. and to support 64 bit operations, I want to expand. If I can set up the operation actions for the same type globally, then I can avoid to

Notice that PromoteVectorOp is called after the type legalization legalized all of the types in the program. It legalizes the *operations*, not the types. So, you should only see legal types (Legal types are types that fit into your registers). So, if your target has v2i32, I suspect that v4i8 is an illegal because it has a different size. -----Original Message----- From: Villmow, Micah

Salut Sebastian! On 01/06/2012 18:19, Sebastian Pop wrote: > Salut Ivan, > > On Fri, Jun 1, 2012 at 7:22 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi Sebastian, >> >> Le 25/05/2012 18:54, Sebastian Pop a écrit : >>> On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org> wrote: >>>> On Thu, May 24, 2012 at

Hi Finkel, Le 23/03/2012 05:50, Hal Finkel a écrit : > The PowerPC backend on PPC64 for non-Darwin (SVR4 ABI) systems > currently has a problem handling integer types smaller than 64 bits. > This is because the ABI specifies that these types are zero-extended to > 64 bits on the stack and the default logic provided in LegalizeDAG does > not use that convention. Specifically, for

Here is the problem explained more. Normally there is a 64 bit register that is the result of certain multiply and divide instructions. It's really 2 32 bit registers. This is like HI[0]/Lo[0] In fact there are four such pairs, only the 0th pair available to basic multiply and divide. But DSP instructions have access to 4 , Hi[i],Lo[i], i=0..3 We want the register allocator to allocate

I am trying to lower all llvm operations to 8-bit. So far I was trying to have llvm do all that for me using things like: setOperationAction(ISD::ADD, MVT::ii,Promote); setOperationAction(ISD::ADD, MVT::i8,Legal); setOperationAction(ISD::ADD, MVT::i16,Expand); setOperationAction(ISD::ADD, MVT::i32,Expand); However, I keep getting an assertion failure that operation can not be expanded.

On Tue, Mar 15, 2016 at 2:21 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 3/15/2016 4:16 PM, Rail Shafigulin via llvm-dev wrote: > >> Below is the output of llc with a -debug-only=isel. As you could see the >> output type for load, store, and add changes from v4i32 to i32 during >> legalization. How can I preserve the output type to