similar to: [LLVMdev] How to prevent LLVM from undoing a custom lowering

The architecture that I'm targeting with an LLVM back end has SRA instructions for all its data sizes, but is missing SRL instructions for some data sizes. I'm having trouble with the SelectionDAGISel::ShrinkDemandedOps() pass. Although it runs after the DAG has been legalized, it replaces legal SRAs with illegal SRLs, which results in failures in instruction selection. Is there a

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 simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

I am trying to understand how LLVM does code generation and I have a couple of questions. I am using LLVM 2.6. First, if I want to change the name of an instruction, all I need to do is to modify the XXXInstrInfo.td, right? Using Sparc as an example, if I wanted to output "mysra" instead of "sra", in SparcInstrInfo.td, I would write, defm SRA : F3_12<"mysra",

On Sunday 03 January 2010 01:00, Chris Lattner wrote: > On Jan 1, 2010, at 12:51 PM, mmms1841 wrote: > > I am trying to understand how LLVM does code generation and I have a > > couple of questions. I am using LLVM 2.6. > > > > First, > > if I want to change the name of an instruction, all I need to do is to > > modify the XXXInstrInfo.td, right? Using Sparc

On Jan 1, 2010, at 12:51 PM, mmms1841 wrote: > I am trying to understand how LLVM does code generation and I have a couple of questions. > I am using LLVM 2.6. > > First, > if I want to change the name of an instruction, all I need to do is to modify the XXXInstrInfo.td, right? > Using Sparc as an example, if I wanted to output "mysra" instead of "sra",

Duncan Sands wrote: > Hi Greg, > >> 1) What causes the Initial selection DAG code to choose an any_extend >> over a sign_extend (or zero_extend)? > > because it is more efficient: the backend gets more choice in how to do > it, and at the same time it tells the optimizers that the extra bits > contain rubbish, which gives them more freedom to reason. Makes sense,

Hi, I'm building a backend for a 64-bit target based on the existing Mips 32 one and I've come up against a problem with 32-bit loads. If you load a 32-bit value into a register this needs extending to fit into a native 64-bit register. The initial selection DAG acomplishes this using an any_extend node, which isn't handled later on by any instruction selector and thus LLVM

Hi, I am defining Hexagons version of ReplaceNodeResults to change the a node of the type A: i8 = INTRINSIC_WO_CHAIN ... , ... , To B: SIGN_EXTEND (A) After returning from my function, the type legalizer calss ReplaceValuesUsesWith to replace the uses of A with B. Unfortunately, it replaces the use of A in the new node B too. So the node now is B: SIGN_EXTEND(B) , which is clearly bad and the

Hi Greg, >>> 1) What causes the Initial selection DAG code to choose an any_extend >>> over a sign_extend (or zero_extend)? >> >> because it is more efficient: the backend gets more choice in how to do >> it, and at the same time it tells the optimizers that the extra bits >> contain rubbish, which gives them more freedom to reason. > Makes sense,

-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Wednesday, February 18, 2009 3:01 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Possible error in LegalizeDAG On Wed, Feb 18, 2009 at 10:14 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I'm still trying to track down some

LLVM appears to support Library functions for ISD::SRA ,ISD::SHL, and ISD::SRL, as they are properly defined in RuntimeLibCalls.def. The library functions defined in RuntimeLibCalls.def (among others) are these: HANDLE_LIBCALL(SRA_I16, "__ashrhi3") HANDLE_LIBCALL(SRA_I32, "__ashrsi3") HANDLE_LIBCALL(SRA_I64, "__ashrdi3") However, setting

On Thu, Feb 19, 2009 at 10:35 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > On the hardware that I am targeting, which is not a CPU, I must support > i8 loads, however the hardware only supports natively 32bit aligned > loads, therefore I have to read in 4 i8's and unpack them and shift them > based on the read address. So any i8 load has a 75% chance of being >

On Tue, 9 May 2017, Krzysztof Parzyszek wrote: > def: Pat<(ld (add (WRAPPER RC:$addr), (sign_extend RC:$offset))), > (load_instruction_rr RC:$addr, RC:$offset)>; > > Where "load_instruction" is a machine load instruction with base address and > an offset, both in registers, and RC is the corresponding register class. Can I also use something more complex

Hello, I'm working in adding support for 64-bit integers to my target. I'm using LLVM to decompose the 64-bit integer operations by using 32-bit registers wherever possible and emulating support where not. When looking at the bit shift decomposition I saw what seems to be a bug in the implementation. The affected function is ExpandShiftWithUnknownAmountBit in LegalizeIntegerTypes.cpp.

Hi Eli, Thanks for pointing to the CTLZ_ZERO_UNDEF “LibCall” implementation. I have not it in the version that I am currently using, so it’s nice to know that it’s implemented now. Incidentally, the CTLZ… implementation is IDENTICAL to what I am proposing for the Shifts. This is not just adding support for “out-of-tree-targets”, but giving consistency to the fact that we have perfectly defined

Hi James/Tim, I am trying to add a patterns for SMLALBB I think these two assembly patterns can be reduced to SMLALBB using tablegen. 1) smulbb r2, r3, r2 adds r0, r2, r0 (RdLo) asr r3, r2, #31 adc r1, r3, r1 (RdHi) ==> smlalbb r0, r1, r3, r2 I have added pattern in def SMLALBB : AMulxyI64< ..... as below :- [] modified to ---> [((set GPR:$RdLo,

On Mon, 8 May 2017, Krzysztof Parzyszek via llvm-dev wrote: > You can create the differentiation between objects in the data memory and in > the program memory in LowerGlobalAddress (e.g. you can create different ISD > opcodes that generate these addresses) and then use those to select > corresponding instructions. Right, which is how I also understand Zhai Xiang's suggestion

Hi all, I met the error while compiling the code with vector type with some architecture. IR is as following. %cmp = icmp sgt <3 x i8> %x, zeroinitializer %sub = sub <3 x i8> zeroinitializer, %x %cond = select <3 x i1> %cmp, <3 x i8> %x, <3 x i8> %sub 'select' IR is converted to 'vselect' dag and is combined to 'sra (X, size(X)-1); xor

Hi Eli, First of all, please I would appreciate that you try to not confuse my limited use of English with stupidity or lack or criteria in other subjects. I’m not English native, so please keep that in mind. You have been significantly helpful in the recent past so please keep on. Interestingly, you made a mention of a related but not identical issue. It is true that most (or all) processors

Hi Greg, > 1) What causes the Initial selection DAG code to choose an any_extend > over a sign_extend (or zero_extend)? because it is more efficient: the backend gets more choice in how to do it, and at the same time it tells the optimizers that the extra bits contain rubbish, which gives them more freedom to reason. > 2) What does any_extend actually signify? Presumably this