similar to: [LLVMdev] store addrspace qualifier

Mon Ping, Thanks for the tip, but I can't for the life of me seem to get the Value from a StoreSDNode. From looking at the SelectionDAGNodes header file, the only class that has the getValue function call is SrcValueSDNode that returns a Value type. The only class that has getType is a ConstantPoolSDNode. I don't think that ConstantPoolSDNode is what I want and when I try to cast the

The address qualifier is stored in the type of %result. From that operand, you can get the Value and then call getType. The type for result should be a PointerType which you cast to a PointerType and get the getAddressSpace e.g. cast<PointerType>(Ty)->getAddressSpace() -- Mon Ping On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: > How do I access the address qualifier

hi, i am building selectionDAG by my own code, but got a assertion fail said "SrcValue is not a pointer?". but since the comment above the SrcValueSDNode said: "SrcValueSDNode - An SDNode that holds an arbitrary LLVM IR Value." why the llvm value of SrcValueSDNode must be with PointerType? is that assertion necessary? thanks a lots. regards --ether

Hello Ether, I think it is referring to the Value class (captial V) whose documentation is found at http://llvm.org/doxygen/classllvm_1_1Value.html . It has to be a pointer because the Value class is a parent class to many many child classes. --Sam ----- Original Message ---- > From: ether zhhb <etherzhhb at gmail.com> > To: LLVM Developers Mailing List <llvmdev at

Hi All, Some targets don't provide subword (e.g., i8 and i16 for a 32-bit machine) load and store instructions, so currently we have to custom-lower Load- and StoreSDNodes in our backends. For examples, see LowerLOAD() and LowerSTORE() in {XCore,CellSPU}ISelLowering.cpp. I believe it's possible to support this lowering in a target-agnostic fashion in LegalizeDAG.cpp, similar to

In order to the code generators to lower functions arguments that have the "byval" attribute, they would have to access the original argument Type. For example, on linux x86_64 {i64, i64} should be passed on registers and {i64, i64, i64} goes on the stack. The problem is that when looking at (for example) FORMAL_ARGUMENTS, the only thing that is present is the type of the pointer itself

Hi all, All of the data types are 32 bits and the pointer is 32 bit. Therefore, I need word adressing instead of byte adressing to use 8 GB memory. I was told that R600 uses word adressing and I looked at its codes but I could not find where the backends handles word adressing. Do you have any ideas about it? Thanks in advance. -------------- next part -------------- An HTML attachment was

Hi All, I'm writing a backend for a target which only supports 4-byte, 4-byte-aligned loads and stores. I custom-lower all {*EXT}LOAD and STORE nodes in TargetISelLowering.cpp to take advantage of all alignment information available to the backend, rather than treat each load and store conservatively, which takes O(10) instructions. My target's allowsUnalignedMemoryOperations()

On 16 Jul 2011, at 03:34, Matt Johnson wrote: > Hi All, > Some targets don't provide subword (e.g., i8 and i16 for a 32-bit > machine) load and store instructions, so currently we have to > custom-lower Load- and StoreSDNodes in our backends. For examples, see > LowerLOAD() and LowerSTORE() in {XCore,CellSPU}ISelLowering.cpp. I > believe it's possible to

On Thu, 6 Sep 2018 at 20:01, Tim Northover <t.p.northover at gmail.com> wrote: > I just did a very quick experiment where I made lowerFP_TO_SINT and > lowerFP_TO_SINT_STORE return SDValue() (which is the marker for "I > don't want to handle this"). I just tried this, but the compiler still crashes with the same error. Maybe our experiments were different. To make

Hi Eli, On 07/27/2011 04:59 PM, Eli Friedman wrote: > On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson > <johnso87 at crhc.illinois.edu> wrote: >> Hi All, >> I'm writing a backend for a target which only supports 4-byte, >> 4-byte-aligned loads and stores. I custom-lower all {*EXT}LOAD and >> STORE nodes in TargetISelLowering.cpp to take advantage of

On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson <johnso87 at crhc.illinois.edu> wrote: > Hi All, >     I'm writing a backend for a target which only supports 4-byte, > 4-byte-aligned loads and stores.  I custom-lower all {*EXT}LOAD and > STORE nodes in TargetISelLowering.cpp to take advantage of all alignment > information available to the backend, rather than treat each

On Wed, Jul 27, 2011 at 3:50 PM, Matt Johnson <johnso87 at crhc.illinois.edu> wrote: > Hi Eli, > > On 07/27/2011 04:59 PM, Eli Friedman wrote: >> >> On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson >> <johnso87 at crhc.illinois.edu>  wrote: >>> >>> Hi All, >>>     I'm writing a backend for a target which only supports 4-byte,

Hi folks, TableGen provides sufficiently rich syntax for expressing target instruction set. Nevertheless, when I wrote the PTX backend, I observed that some redundancy in TableGen can be further eliminated through macro expansion of for-loops. The semantics of a for-loop is expanding the for-loop body, and so it is equivalent to manually unroll the loop (see example #1). I believe the for-loop

Hi, Sent via the Samsung Galaxy Note® 3, an AT&T 4G LTE smartphone -------- Original message -------- From: Gurunath Kadam via llvm-dev <llvm-dev at lists.llvm.org> Date: 11/27/2016 7:49 PM (GMT-06:00) To: llvm-dev at lists.llvm.org Subject: [llvm-dev] LLVM Pass for Instructions in Function (error Hi, Please find the embedded code. Also you may follow

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

The code excerpt is from IPO/GlobalOpt.cpp // If this is a first class global and has only one accessing function // and this function is main (which we know is not recursive we can make // this global a local variable) we replace the global with a local alloca // in this function. // // NOTE: It doesn't make sense to promote non single-value types since we // are

Every GlobalAddress has a GlobalValue, Every GlobalValue is a PointerType, Every PointerType has an AddressSpace. So is it ok to add a method getAddressSpace in GlobalAddressSDNode class itself? Currently we have to do GSDN->getGlobal()->getType()->getAddressSpace(). - Sanjiv

> On Nov 27, 2016, at 6:40 PM, Gurunath Kadam via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sandeep, > > Thanks. > > One question about: > > Value* AddrPointer = Inst->getIperand(0); > > So this works for LVALUE(S) i.e. in my case pointer on LHS of '='. I cannot find anything online about getloperand online. > > For reference

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli