Displaying 7 results from an estimated 7 matches for "loadexttype".
Did you mean:
loader_type
2013 Mar 04
1
[LLVMdev] Custom Lowering of ARM zero-extending loads
...de to accomplish that:
1. Register the ZEXTLOAD for custom lowering:
setLoadExtAction(ISD::ZEXTLOAD, MVT::i16, Custom);
2. Implement a custom lowering function:
static SDValue LowerExtLoad(SDValue Op, SelectionDAG &DAG) {
LoadSDNode *LD = dyn_cast<LoadSDNode>(Op.getNode());
ISD::LoadExtType ExtType = LD->getExtensionType();
if (LD->getExtensionType() == ISD::ZEXTLOAD) {
DEBUG(errs() << "ZEXTLOAD\n");
SDValue Chain = LD->getChain();
SDValue Ptr = LD->getBasePtr();
DebugLoc dl = Op.getNode()->getDebugLoc();
SDValue LdResult = DAG.get...
2012 Feb 23
1
[LLVMdev] Simple question on sign
...d not have [(set ... )] in it's pattern, i see this is the
difference in instruction description for the mips case.
I'm wondering how llvm knows when to use certain compare instructions such
as SETNE or SETUNE? And for sign or zero extending loads? I can see the
PatFrags described and the LoadExtType enum defined, and the use of zext and
sext to differentiate what containers the values are being loaded into in
the IR.
Basically I'm trying to describe patterns for automatically selecting
between various multiplication instructions:
#define MULL(t,s1,s2) t = (s1) * INT16(s2)
#define MULLU(t...
2012 Feb 23
0
[LLVMdev] Simple question on sign
Hi Sam,
I am not a MIPS expert by any means, so YMMV, but: MIPS addu only differs to
"add" in its (non)setting of the overflow flag. Because LLVM doesn't provide
a way via the IR to access the overflow flag, a special notation isn't
required in the IR to distinguish the two operations.
Do you have another example?
Cheers,
James
-----Original Message-----
From:
2012 Feb 23
2
[LLVMdev] Simple question on sign
Thanks for the replies guys but I think I should have phrased my question
better... looking at the Mips backend there are machine instructions that
operate on signed and unsigned data, such as add and addu. And like Mips, I
need to specify unsigned specific instructions, so how do these get chosen
between if the LLVM IR does not carry type data? A very general point in the
right direction is all i
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2009 May 21
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
...Result = DAG.getExtLoad(ISD::EXTLOAD, dl, NVT, Tmp3, VAList, NULL, 0, VT);
- }
- // Remember that we legalized the chain.
- AddLegalizedOperand(Op.getValue(1), LegalizeOp(Result.getValue(1)));
- break;
-
- case ISD::LOAD: {
- LoadSDNode *LD = cast<LoadSDNode>(Node);
- ISD::LoadExtType ExtType = ISD::isNON_EXTLoad(Node)
- ? ISD::EXTLOAD : LD->getExtensionType();
- Result = DAG.getExtLoad(ExtType, dl, NVT,
- LD->getChain(), LD->getBasePtr(),
- LD->getSrcValue(), LD->getSrcValueOffset(),
-...