Displaying 9 results from an estimated 9 matches for "ismachineopcode".
2010 Aug 08
1
[LLVMdev] Suspicious code in backend scheduler
...cpp, one can find this
piece of code:
SUnit *CopyFromSU = CreateNewSUnit(NULL);
and then in the same files:
SUnit *CreateNewSUnit(SDNode *N) {
[...]
SUnit *NewNode = NewSUnit(N);
And finally in ScheduleDAGSDNodes.cpp:
SUnit *ScheduleDAGSDNodes::NewSUnit(SDNode *N) {
[...]
if (N->isMachineOpcode() && [...]
So basically, it means that calling CreateNewSUnit with NULL will call
NewSUnit with NULL and with result in NULL->isMachineOpcode() which would
certainly trigger a segfault.
Now I'm highly surprized because I still haven't encountered any segfault in
the scheduler ye...
2011 Nov 09
1
[LLVMdev] .debug_info section size in arm executable
On Nov 9, 2011, at 2:12 PM, Chris Lattner wrote:
> On Nov 9, 2011, at 1:08 PM, Jim Grosbach wrote:
>>> On Nov 9, 2011, at 10:49 AM, Jim Grosbach wrote:
>>>>>
>>>>> It's not good, but people do it. Also constructing enums via & and | etc. It'd be nice to be able to get the name of whatever it is that the code generator actually produced :)
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 further passes that eliminate anything.
Anyway, I have another test program, that could point to my bug:
int formal_args_3(int p1, int p2,...
2014 Oct 31
2
[LLVMdev] Virtual register def doesn't dominate all uses
...ption --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 further passes that eliminate anything.
>>
>> Anyway, I have anothe...
2013 Oct 21
0
[LLVMdev] Instruction Emitter crash when emitting glued InlineAsm SDNode
...i,
I'm getting an Instruction emitter crash when emitting an INLINEASM
SDNode that is Glued to other nodes.
The crash happens at line 808 of file
llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:
const MCInstrDesc &MCID = TII->get(F->getMachineOpcode());
with the assertion:
assert(isMachineOpcode() && "Not a MachineInstr opcode!");
I'm not a great expert of the instruction emitter part unfortunately,
but I tried to track down the problem and I managed to fix it for my
case (now the instruction emitter outputs the InlineAsm correctly
without crashes and the inlined...
2014 Nov 01
2
[LLVMdev] Virtual register def doesn't dominate all uses
...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 further passes that...
2009 Dec 18
2
[LLVMdev] [PATCH] dbgs() Use
...<< "Selecting: ";
+ dbgs() << std::string(Indent, ' ') << "Selecting: ";
Node->dump(CurDAG);
- errs() << '\n';
+ dbgs() << '\n';
});
Indent += 2;
#endif
@@ -1721,9 +1721,9 @@
if (Node->isMachineOpcode()) {
#ifndef NDEBUG
DEBUG({
- errs() << std::string(Indent-2, ' ') << "== ";
+ dbgs() << std::string(Indent-2, ' ') << "== ";
Node->dump(CurDAG);
- errs() << '\n';
+ dbgs() <&l...
2017 Feb 11
2
Specify special cases of delay slots in the back end
Hello.
Hal, the problem I have is that it doesn't advance at the next available instruction
- it always gets the same store. This might be because I did not specify in a file like
[Target]Schedule.td the functional units, processor and instruction itineraries.
Regarding the Stalls argument to my method
[Target]DispatchGroupSBHazardRecognizer::getHazardType() I always get the
2014 Oct 24
2
[LLVMdev] Virtual register def doesn't dominate all uses
Hi!
During my backend development I get the error message for some tests:
*** Bad machine code: Virtual register def doesn't dominate all uses. ***
(C source-code, byte-code disassembly and printed machine code at the end of the email)
The first USE of vreg4 in BB#1 has no previous DEF in BB#0 or #1. But why? I can't see how the LLVM byte-code is transformed to the lower machine code.