Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] alias-aware scheduling"
2008 Apr 24
0
[LLVMdev] FoldingSetNodeID operations inefficiency
Hi Chris,
This is a good idea and I started thinking in that direction already.
But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to.
For example now:
> PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the
> TokenFactor node by SelectionDAGLowering::getRoot called from the
>
2006 Dec 20
1
[LLVMdev] alias-aware scheduling
On Tue, Dec 19, 2006 at 01:31:10PM -0800, Evan Cheng wrote:
>
> On Dec 19, 2006, at 12:13 PM, Dan Gohman wrote:
>
> > Hello,
> >
> > I did a little experiment modifying LLVM to be able to use alias-
> > analysis
> > information in scheduling so that independent memory operations may be
> > reordered.
>
> I am not sure if it is a good idea to
2008 Apr 28
1
[LLVMdev] FoldingSetNodeID operations inefficiency
Hi Chris,
Your were totally right with your suggestion.
I have implemented the code that :
a) does not merge multiple TokenFactor nodes in the DAGCombiner::visitTokenFactor(), if the resulting TF node would contain more than 64 operands.
b) produces a bunch of TokenFactor nodes with at most 64 operands,
instead of one huge TokenFactor in the SelectionDAGLowering::getRoot().
If we have n
2008 Apr 23
1
[LLVMdev] FoldingSetNodeID operations inefficiency
Hi,
While profiling LLVM using my test-cases with huge MBBs, I noticed that
FoldingSetNodeID operations (ComputeHash,insertion,etc) may become
really inefficient for the nodes, which have very many operands.
I can give you an example of what is meant by "very many". In my
test-case (you can fetch it from here
http://llvm.org/bugs/attachment.cgi?id=1275), which is just one HUGE MBB
2006 Dec 19
0
[LLVMdev] alias-aware scheduling
On Dec 19, 2006, at 12:13 PM, Dan Gohman wrote:
> Hello,
>
> I did a little experiment modifying LLVM to be able to use alias-
> analysis
> information in scheduling so that independent memory operations may be
> reordered.
I am not sure if it is a good idea to do this at scheduling time.
LLVM explicitly models control flows dependencies as chain operands.
This eliminated
2007 Sep 24
2
[LLVMdev] RFC: Tail call optimization X86
On 24 Sep 2007, at 09:18, Evan Cheng wrote:
> +; RUN: llvm-as < %s | llc -march=x86 -mattr=+sse2 -stats -info-
> output-file - | grep asm-printer | grep 9
> +; change preceeding line form ... | grep 8 to ..| grep 9 since
> +; with new fastcc has std call semantics causing a stack adjustment
> +; after the function call
>
> Not sure if I understand this. Can you illustrate
2007 Sep 24
0
[LLVMdev] RFC: Tail call optimization X86
On Sep 24, 2007, at 2:25 AM, Arnold Schwaighofer wrote:
>
> On 24 Sep 2007, at 09:18, Evan Cheng wrote:
>> +; RUN: llvm-as < %s | llc -march=x86 -mattr=+sse2 -stats -info-
>> output-file - | grep asm-printer | grep 9
>> +; change preceeding line form ... | grep 8 to ..| grep 9 since
>> +; with new fastcc has std call semantics causing a stack adjustment
>>
2007 Sep 24
0
[LLVMdev] RFC: Tail call optimization X86
Hi Arnold,
This is a very good first step! Thanks! Comments below.
Evan
Index: test/CodeGen/X86/constant-pool-remat-0.ll
===================================================================
--- test/CodeGen/X86/constant-pool-remat-0.ll (revision 42247)
+++ test/CodeGen/X86/constant-pool-remat-0.ll (working copy)
@@ -1,8 +1,10 @@
; RUN: llvm-as < %s | llc -march=x86-64 | grep LCPI | count 3
;
2014 Dec 16
3
[LLVMdev] ScheduleDAGInstrs.cpp
Hi,
Thank you for the reply.
>It looks to me like we can choose any subset of edges here and be correct. We're basically trying to prune/pinch the DAG edges here. They can easily blow up with AA sched. I would guess that isCtrl() edges are good ones to bypass because they could be a low-latecy edges, whereas true data dependencies from a load are expected to be >higher latency, so they
2008 Nov 17
0
[LLVMdev] Assertion `castIsValid(getOpcode(), S, Ty) && "Illegal BitCast"' faile
ok.. you are right. I had not inserted the AllocaInst in the function. Thanks a lot for solving my problem yet again :)
--- On Mon, 11/17/08, Eli Friedman <eli.friedman at gmail.com> wrote:
> From: Eli Friedman <eli.friedman at gmail.com>
> Subject: Re: Assertion `castIsValid(getOpcode(), S, Ty) && "Illegal BitCast"' faile
> To: bhavi63 at yahoo.com
2014 Dec 14
2
[LLVMdev] ScheduleDAGInstrs.cpp
Hello again,
Sorry -- I think I found the problem somewhere else. I was a bit confused and missed the fact that adjustChainDeps() is called a few lines down and does just what I wanted :-)
I would like to instead ask another question:
Why is I->isCtrl() used in code like
// Iterate over chain dependencies only.
for (SUnit::const_succ_iterator I = SUb->Succs.begin(), E =
2006 May 05
0
[LLVMdev] ExecutionEngine blew the stack ?
(resending with smaller attachement)
Segfault in EE->getPointerToFunction.
I think it's blown the stack, gdb reports a never ending backtrace (below).
I generate llvm assembly and parse/verify OK.
Attached is the assembly. It is the smallest example
generated that causes the segfault.
If this EE uses a recursive function (??), it seems an inherent limitation
in how big llvm functions
2006 May 05
2
[LLVMdev] ExecutionEngine blew the stack ?
Segfault in EE->getPointerToFunction.
I think it's blown the stack, gdb reports a never ending backtrace (below).
I generate llvm assembly and parse/verify OK.
Attached is the assembly. It is the smallest example
generated that causes the segfault.
If this EE uses a recursive function (??), it seems an inherent limitation
in how big llvm functions can be.
Simon.
gdb backtrace:
#0
2006 May 05
1
[LLVMdev] ExecutionEngine blew the stack ?
Hi Simon,
You're probably right. LLVM's instruction selector is recursive so it
can run out of stack space. Select_store used to have enormous stack
frame (thanks to some gcc issues), we had to do all kinds of tricks
to get it under control. I just took a look at it, it's around 0.7k.
It used to be around 20k on x86 Mac OS X.
It's also possible that it has gotten into a
2008 Apr 22
0
[LLVMdev] RFC: PowerPC tail call optimization patch
On Apr 22, 2008, at 4:58 AM, Arnold Schwaighofer wrote:
> On Tue, Apr 22, 2008 at 12:30 AM, Evan Cheng <evan.cheng at apple.com>
> wrote:
>> More nitpicks:
>> ...
>> No need for else here. :-)
> Done
>> SPDiff = (int)CallerMinReservedArea - (int)ParamSize;
>>
>> Just change last statement to
>> int SPDiff = (int)...
> Done
>>
2008 Jul 11
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hi Evan,
Evan Cheng wrote:
> This does not patch cleanly for me (PPCISelLowering.cpp). Can you
> prepare a updated patch?
This should work, though I won't have access to my test box now until
next Thursday so no guarantees :)
Cheers,
Gary
--
http://gbenson.net/
-------------- next part --------------
Index: lib/Target/PowerPC/PPCISelLowering.h
2007 Sep 25
0
[LLVMdev] RFC: Tail call optimization X86
On Sep 25, 2007, at 12:01 AM, Arnold Schwaighofer wrote:
>>> FastCC use to be caller pops arguments so there was no stack
>>> adjustment after the
>>> call to qux. Now FastCC has callee pops arguments on return
>>> semantics
>>> so the
>>> x86 backend inserts a stack adjustment after the call.
>>>
>>> _array:
>>>
2008 Jul 09
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Ah, didn't see that, that's what comes of trying to do something at
5pm :) I attached an updated patch which creates a virtual register
instead of using R0. How does this look?
Cheers,
Gary
Dan Gohman wrote:
> PPCTargetLowering::EmitInstrWithCustomInserter has a reference
> to the current MachineFunction for other purposes. Can you use
> MachineFunction::getRegInfo instead?
2008 Apr 21
0
[LLVMdev] RFC: PowerPC tail call optimization patch
On Apr 16, 2008, at 10:07 AM, Arnold Schwaighofer wrote:
> Hello Dale,
>
> this is an updated version of the tail call optimization patch for
> powerpc. could you have a look at it?
>
> i added code to support ppc64 (untested, will try to get access to
> ppc64 on a friend's machine).
> incorporated evan's formatting suggestions. ;)
>
> will run another round
2008 Nov 17
1
[LLVMdev] Assertion `InReg && "Value not in map!"' failed
Ah! I get it now. Thanks a lot !
I changed it to BitCastInst(AI,VoidPtrTy,"",j);
And now I am getting the following error :(. I have been stuck with this error before also. I know I am missing out something silly. What is the cause of this error and Please let me know how to fix it.
/home/bhavani/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1130: llvm::SDOperand