Displaying 3 results from an estimated 3 matches for "avrisd".
Did you mean:
avoid
2016 Jun 04
4
Gluing arbitrary nodes together
...into a standard
ISD::LOAD with the save/restore/interrupt nodes glued to it.
Here’s what I have so far:
// Store `SREG`
auto Save = DAG.getCopyFromReg(DAG.getEntryNode(), DL, AVR::SREG, MVT::i8);
// Disable interrupts (`clr` is equivalent to `bclr 7`).
auto ClearInterrupts = DAG.getNode(AVRISD::BCLR, DL, MVT::Glue,
DAG.getConstant(7, DL, MVT::i8));
// Perform the nonatomic load.
auto *Node = cast<AtomicSDNode>(AtomicOp.getNode());
SDValue Load = DAG.getExtLoad(ISD::EXTLOAD, SDLoc(AtomicOp),
AtomicOp.getValueType(),
Node->getChain(), Node-...
2017 May 09
2
Instruction selection for 'load' based on static vs. dynamic data
...D
> opcodes that generate these addresses) and then use those to select
> corresponding instructions.
Right, which is how I also understand Zhai Xiang's suggestion with the
link to existing AVR target code. This is already done to some extent,
since the AVR backend already inserts an AVRISD::WRAPPER node to mark the
static data's address.
However, what's still missing with that plan is how to propagate that
information "upwards". By the time it gets to instruction selection, the
`getelementptr` is already expanded into some arithmetic expression of a
base addres...
2017 May 07
3
Instruction selection for 'load' based on static vs. dynamic data
Hi,
I've been looking at the new AVR backend lately, and one issue I've
found is that all 'load' IR instructions are matched using the 'ld'
AVR instruction, including 'load's for lookup tables generated from
switches.
On the AVR architecture, RAM and the program image are in completely
separated namespaces. There's a distinct 'lpm' (Load from Program