Displaying 9 results from an estimated 9 matches for "scheduledagtopologicalsort".
2010 Jun 08
2
[LLVMdev] Always unfold memory operand
...,
I have tried this, but the resulting tool-chain was broken.
There are only two references to "CALL64m": the definition in
X86Instr64bit.td, and an entry in X86InstrInfo.cpp.
After commenting both out, compilation of a large application fails with:
llc: ScheduleDAG.cpp:462: void
llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion
`Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong
topological sorting"' failed.
bugpoint produced this minimal example which triggers the problem:
define ccc void @ArgsFree() nounwind {
entry:
%0 = l...
2010 Jun 09
0
[LLVMdev] Always unfold memory operand
...ut the resulting tool-chain was broken.
> There are only two references to "CALL64m": the definition in
> X86Instr64bit.td, and an entry in X86InstrInfo.cpp.
> After commenting both out, compilation of a large application fails with:
> llc: ScheduleDAG.cpp:462: void
> llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion
> `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong
> topological sorting"' failed.
> bugpoint produced this minimal example which triggers the problem:
> define ccc void @ArgsFree() nounwind...
2012 Jan 17
1
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
...;ve implemented a cycle check, but this
increases the algorithmic complexity of the pair-selection process, and
makes the vectorizer quite slow on some blocks. I can see two ways to
proceed here:
1. Improve the cycle detection algorithm used (for example, I can use
the algorithm currently used for
ScheduleDAGTopologicalSort::WillCreateCycle, or something similar).
2. Late abort on non-trivial cycles. This will make the fusing process
more expensive, but will not increase the algorithmic complexity. It
would, however, degrade the quality of the vectorization, because it
would mean that pairs otherwise selected for vec...
2010 Jun 09
1
[LLVMdev] Always unfold memory operand
...in was broken.
> > There are only two references to "CALL64m": the definition in
> > X86Instr64bit.td, and an entry in X86InstrInfo.cpp.
> > After commenting both out, compilation of a large application fails with:
> > llc: ScheduleDAG.cpp:462: void
> > llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion
> > `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong
> > topological sorting"' failed.
> > bugpoint produced this minimal example which triggers the problem:
> > define ccc void...
2010 Jun 08
2
[LLVMdev] Always unfold memory operand
Hi,
I am attempting to modify LLVM to generate code for an architecture which is
nearly identical to X86-64, but with a few minor differences.
In particular, "call" must always have a register operand, and cannot have a
memory operand. Any ideas on how I can express this rule?
Thanks,
- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2010 Jun 08
0
[LLVMdev] Always unfold memory operand
On Tue, Jun 8, 2010 at 2:05 PM, David Meyer <pdox at google.com> wrote:
> Hi,
> I am attempting to modify LLVM to generate code for an architecture which is
> nearly identical to X86-64, but with a few minor differences.
> In particular, "call" must always have a register operand, and cannot have a
> memory operand. Any ideas on how I can express this rule?
Just get
2013 Feb 28
2
[LLVMdev] Calling with register indirect reference instead of memory indirect reference.
...d test case:
int main()
{
extern void (*foo)(int);
foo(2);
return 0;
}
And the problem is that I am seeing an assertion failure with respect to the DAG structure.
.file "<stdin>"
llc: ~/llvm/lib/CodeGen/ScheduleDAG.cpp:510: void llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] && "Wrong topological sorting"' failed.
0 llc 0x000000000117ef3a llvm::sys::PrintStackTrace(_IO_FILE*) + 38
I am wondering if the modification made t...
2012 Jan 17
0
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
Hi,
On Fri, Dec 30, 2011 at 3:09 AM, Tobias Grosser <tobias at grosser.es> wrote:
> As it seems my intuition is wrong, I am very eager to see and understand
> an example where a search limit of 4000 is really needed.
>
To make the ball roll again, I attached a testcase that can be tuned
to understand the impact on compile time for different sizes of a
basic block. One can also
2011 Dec 30
3
[LLVMdev] [llvm-commits] [PATCH] BasicBlock Autovectorization Pass
On 12/29/2011 06:32 PM, Hal Finkel wrote:
> On Thu, 2011-12-29 at 15:00 +0100, Tobias Grosser wrote:
>> On 12/14/2011 01:25 AM, Hal Finkel wrote:
>> One thing that I would still like to have is a test case where
>> bb-vectorize-search-limit is needed to avoid exponential compile time
>> growth and another test case that is not optimized, if
>>