Displaying 20 results from an estimated 22 matches for "dagtodagisel".
2015 Mar 09
2
[LLVMdev] LLVM Backend DAGToDAGISel INTRINSIC
I am currently working on DAGToDAGISel class for MIPS and am trying to
figure out a way to use INTRINSIC_W_CHAIN for an intrinsic which can return
a value.
My intrinsic is defined as:
Intrinsic<[llvm_i32_ty],[llvm_i32_ty,llvm_i32_ty,llvm_i32_ty,llvm_i32_ty],[IntrReadWriteArgMem]>;
i.e. it has four arguments and one return value...
2013 Mar 27
2
[LLVMdev] LLVM pass question
What I am thinking of now is to just register the MIPS116 and MIPS32
DAGToDAGISel passes and then within run on machine function, I can just
return if the current mode indicates that mips16 is needed for example,
so the run on machine function for Mips32 would return immediately.
On 03/27/2013 10:05 AM, Reed Kotler wrote:
> I guess another way to do this is to just register...
2013 Mar 27
2
[LLVMdev] LLVM pass question
I'm implementing this ability to switch between mips16 and mips32 on a
per function basis.
One issue that I've run into is regarding the DAGToDAGIsel pass.
We have a different subclass for mips16 and non mips16 ( conceivably
later there could be a separate one for micromips).
I need to run a different pass depending on whether it's mips16 or mips32.
My initial plan was to create a dummy ModuleDAGToDAGIsel whose sole
purpose in it's...
2013 Mar 27
0
[LLVMdev] LLVM pass question
...least passes in this case.
So in principle turn on the dual mode now and debug whatever misc is left.
For this I insert another pass before the mips16 and non mips16 passes.
On 03/27/2013 10:19 AM, Reed Kotler wrote:
> What I am thinking of now is to just register the MIPS116 and MIPS32
> DAGToDAGISel passes and then within run on machine function, I can just
> return if the current mode indicates that mips16 is needed for example,
> so the run on machine function for Mips32 would return immediately.
>
> On 03/27/2013 10:05 AM, Reed Kotler wrote:
>> I guess another way to do th...
2008 Dec 01
2
[LLVMdev] TargetISelLowering
...t think that the TargetLowering classes have anything to do with
instruction selection [any more?]). However, the inconsistent filenames are a
bit confusing. Perhaps somebody should rename the lot of them?
The same goes for <Target>ISelDAGToDAG.cpp, which defines a class called
<Target>DAGToDAGISel.
Gr.
Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081201/241b3ef7/attachment.sig>
2013 Mar 27
0
[LLVMdev] LLVM pass question
...s for
mips16 and mips32 and have them return immediately if it is not their
turn to run.
On 03/27/2013 08:58 AM, Reed Kotler wrote:
> I'm implementing this ability to switch between mips16 and mips32 on a
> per function basis.
>
> One issue that I've run into is regarding the DAGToDAGIsel pass.
>
> We have a different subclass for mips16 and non mips16 ( conceivably
> later there could be a separate one for micromips).
>
>
> I need to run a different pass depending on whether it's mips16 or mips32.
>
> My initial plan was to create a dummy ModuleDAGToDAGI...
2013 Mar 27
1
[LLVMdev] LLVM pass question
...t; So in principle turn on the dual mode now and debug whatever misc is left.
>
> For this I insert another pass before the mips16 and non mips16 passes.
>
> On 03/27/2013 10:19 AM, Reed Kotler wrote:
>> What I am thinking of now is to just register the MIPS116 and MIPS32
>> DAGToDAGISel passes and then within run on machine function, I can just
>> return if the current mode indicates that mips16 is needed for example,
>> so the run on machine function for Mips32 would return immediately.
>>
>> On 03/27/2013 10:05 AM, Reed Kotler wrote:
>>> I guess...
2016 May 05
2
SelectionDAGISel::Select's API considered harmful
TLDR: Heads up for out of tree backends - you're going to need to update
your *DAGToDAGISel::Select method to unconditionally replace nodes
directly instead of returning the desired replacement.
So I'm working on fixing the undefined behaviour I described in
llvm.org/PR26808. As part of this, we need to stop looking into deleted
SDNodes to check if they were, in fact, deleted. A big...
2016 Oct 21
2
Accessing the associated LLVM IR Instruction for an SDNode used in instruction selection (back end)
...VM IR Instructions to generated SDNodes:
public:
// Alex: added a getter for NodeMap
DenseMap<const Value*, SDValue> &getNodeMap() {
return NodeMap;
}
A small problem is that it seems that when I access the NodeMap in
[Target]DAGToDAGISel::Select(SDNode *Node) method (part of subclass of SelectionDAGISel),
the NodeMap contains quite a few SDNodes tagged as <<Deleted Node!>> (for the nodes that
were already selected).
But the current SDNode, given as parameter to Select() is valid and we can search for
it in NodeM...
2008 Dec 01
0
[LLVMdev] TargetISelLowering
...r, the inconsistent
> filenames are a
> bit confusing. Perhaps somebody should rename the lot of them?
Sure, I'd support renaming them to <target>TargetLowering.cpp etc.
> The same goes for <Target>ISelDAGToDAG.cpp, which defines a class
> called
> <Target>DAGToDAGISel.
The DAGToDAG suffix is actually a pretty old historical artifact at
this point. It would be better to rename the classes and files to
<target>DAGISel.
-Chris
2016 May 21
0
SelectionDAGISel::Select's API considered harmful
Update: All in tree backends now implement `void Select`. I'll be
removing the SelectImpl path on Monday.
Justin Bogner <mail at justinbogner.com> writes:
> TLDR: Heads up for out of tree backends - you're going to need to update
> your *DAGToDAGISel::Select method to unconditionally replace nodes
> directly instead of returning the desired replacement.
>
> So I'm working on fixing the undefined behaviour I described in
> llvm.org/PR26808. As part of this, we need to stop looking into deleted
> SDNodes to check if they were,...
2016 May 23
2
SelectionDAGISel::Select's API considered harmful
...rg> wrote:
> Update: All in tree backends now implement `void Select`. I'll be
> removing the SelectImpl path on Monday.
>
> Justin Bogner <mail at justinbogner.com> writes:
>> TLDR: Heads up for out of tree backends - you're going to need to update
>> your *DAGToDAGISel::Select method to unconditionally replace nodes
>> directly instead of returning the desired replacement.
>>
>> So I'm working on fixing the undefined behaviour I described in
>> llvm.org/PR26808. As part of this, we need to stop looking into deleted
>> SDNodes to...
2019 Aug 26
2
LLVM X86 backend combineIncDecVector's transform
No objections from me to make it run later. I didn't see the potential
conflicts when I added that code. Delayed combine, custom lowering, or
DAGToDAGISel all seem like viable options to me.
On Mon, Aug 26, 2019 at 2:04 PM Roman Lebedev <lebedev.ri at gmail.com> wrote:
> I have previously posted these two patches:
>
> [X86][CodeGen][NFC] Delay `combineIncDecVector()` from DAGCombine to
> X86DAGToDAGISel
> https://reviews.llvm.o...
2016 Oct 24
2
Accessing the associated LLVM IR Instruction for an SDNode used in instruction selection (back end)
...object relating LLVM IR Instructions to generated SDNodes:
>> public: // Alex: added a getter for NodeMap DenseMap<const Value*, SDValue>
>> &getNodeMap() { return NodeMap; }
>>
>> A small problem is that it seems that when I access the NodeMap in
>> [Target]DAGToDAGISel::Select(SDNode *Node) method (part of subclass of
>> SelectionDAGISel), the NodeMap contains quite a few SDNodes tagged as <<Deleted
>> Node!>> (for the nodes that were already selected). But the current SDNode, given as
>> parameter to Select() is valid and we can sea...
2014 Oct 29
2
[LLVMdev] Virtual register def doesn't dominate all uses
Hi Quentin,
yes, this happens quite late. With the Option --debug-pass=Structure it's in or after "Assembly Printer".
I do have a very simple DAGToDAGISel::Select() method:
SDNode *MyTargetDAGToDAGISel::Select(SDNode *N)
{
SDLoc dl(N);
// default implementation
if (N -> isMachineOpcode()) {
N -> setNodeId(-1);
return NULL; // Already selected.
}
SDNode *res = SelectCode(N);
return res;
}
Is that too simple? There are no...
2014 Oct 31
2
[LLVMdev] Virtual register def doesn't dominate all uses
...t; Hi Boris,
>
> On Oct 29, 2014, at 10:35 AM, Boris Boesler <baembel at gmx.de> wrote:
>
>> Hi Quentin,
>>
>> yes, this happens quite late. With the Option --debug-pass=Structure it's in or after "Assembly Printer".
>> I do have a very simple DAGToDAGISel::Select() method:
>>
>> SDNode *MyTargetDAGToDAGISel::Select(SDNode *N)
>> {
>> SDLoc dl(N);
>> // default implementation
>> if (N -> isMachineOpcode()) {
>> N -> setNodeId(-1);
>> return NULL; // Already selected.
>> }
>> SDN...
2016 May 23
0
SelectionDAGISel::Select's API considered harmful
...backends now implement `void Select`. I'll be
>> removing the SelectImpl path on Monday.
This is done in r270454.
>> Justin Bogner <mail at justinbogner.com> writes:
>>> TLDR: Heads up for out of tree backends - you're going to need to update
>>> your *DAGToDAGISel::Select method to unconditionally replace nodes
>>> directly instead of returning the desired replacement.
>>>
>>> So I'm working on fixing the undefined behaviour I described in
>>> llvm.org/PR26808. As part of this, we need to stop looking into deleted
>...
2019 Aug 26
1
LLVM X86 backend combineIncDecVector's transform
I think DAGToDAG is too late because the build_vector has already been turned into a constant pool load by then so it’s a little difficult to get back. Maybe we can delay it to !DCI.isBeforeLegalizeOps()? That would at least let the first DAG combine and the post type legalization DAG combine see the add, 1.
+Sanjay as well
From: Amaury Séchet <deadalnix at gmail.com>
Sent: Monday, August
2014 Nov 01
2
[LLVMdev] Virtual register def doesn't dominate all uses
...at 10:35 AM, Boris Boesler <baembel at gmx.de> wrote:
>>>
>>>> Hi Quentin,
>>>>
>>>> yes, this happens quite late. With the Option --debug-pass=Structure it's in or after "Assembly Printer".
>>>> I do have a very simple DAGToDAGISel::Select() method:
>>>>
>>>> SDNode *MyTargetDAGToDAGISel::Select(SDNode *N)
>>>> {
>>>> SDLoc dl(N);
>>>> // default implementation
>>>> if (N -> isMachineOpcode()) {
>>>> N -> setNodeId(-1);
>>>>...
2007 Mar 22
1
[LLVMdev] Backend: 2 address + 17bit immediate
...machine code the immediate is a relative offset for the PC).
I have spent some time looking at the PPC and SPARC backends, but obviously
these are much more complicated than what I require to implement.
Consequently, I am not correctly grasping the interactions between
ARCHInstrInfo.td and ARCHDAGToDAGISel.cpp I did manage to hack something
together based on a copy of SPARC (with a SABRE namespace etc) but the
instruction selection was incorrect and I obtained a "Cannot yet
select:0x..." assertion failure from SABREDAGToDAGIsel::SelectCode when I
attempted a
llc -march sabre helloworld....