Displaying 20 results from an estimated 800 matches similar to: "[LLVMdev] "Machine LICM" for Constants?"
2012 Mar 07
0
[LLVMdev] "Machine LICM" for Constants?
Yes machine-licm can and should hoist constant materialization instructions out of the loop. If it's not doing that, it's probably because the target is not modeling the instruction correctly. I would walk through MachineLICM::IsLoopInvariantInst() in the debugger to figure it out. You can also try compiling the same bitcode for a target like ARM or X86 as a comparison.
Evan
On Mar 7,
2012 Mar 08
1
[LLVMdev] "Machine LICM" for Constants?
Thanks for the tip! I looked into it and it looks like the problem as
of SVN HEAD is that the lui and ori instructions in Mips are considered
cheap (1-cycle def-use latency) by MachineLICM::IsCheapInstruction(),
but are not trivially materializable because their register operands are
not always available. This makes MachineLICM::IsProfitableToHoist()
return false, preventing the hoist even
2012 Apr 29
1
[LLVMdev] Not enough optimisations in the SelectionDAG phase?
On 04/29/2012 01:19 PM, Evan Cheng wrote:
> On Apr 24, 2012, at 11:48 PM, Fan Dawei wrote:
>
>> For the following code fragment,
>>
>> ;<label>:27 ; preds = %27, %entry
>> %28 = load volatile i32* inttoptr (i64 2149581832 to i32*), align 8
>> %29 = icmp slt i32 %28, 0
>> br i1 %29, label %27, label
2012 Apr 29
0
[LLVMdev] Not enough optimisations in the SelectionDAG phase?
On Apr 24, 2012, at 11:48 PM, Fan Dawei wrote:
> For the following code fragment,
>
> ; <label>:27 ; preds = %27, %entry
> %28 = load volatile i32* inttoptr (i64 2149581832 to i32*), align 8
> %29 = icmp slt i32 %28, 0
> br i1 %29, label %27, label %loop.exit
>
> loop.exit: ; preds = %27
2012 Apr 25
3
[LLVMdev] Not enough optimisations in the SelectionDAG phase?
For the following code fragment,
; <label>:27 ; preds = %27, %entry
%28 = load volatile i32* inttoptr (i64 2149581832 to i32*), align 8
%29 = icmp slt i32 %28, 0
br i1 %29, label %27, label %loop.exit
loop.exit: ; preds = %27
llc will generate following MIPS code,
$BB0_1:
lui $3, 32800
ori $3, $3, 1032
lw
2012 Apr 05
1
[PATCH] remove unnecesary typedef in bitwriter.c
---
src/libFLAC/bitwriter.c | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/src/libFLAC/bitwriter.c b/src/libFLAC/bitwriter.c
index 651440d..7da4b15 100644
--- a/src/libFLAC/bitwriter.c
+++ b/src/libFLAC/bitwriter.c
@@ -43,12 +43,11 @@
/* Things should be fastest when this matches the machine word size */
/* WATCHOUT: if you change this
2013 Feb 20
3
[LLVMdev] Is va_arg correct on Mips backend?
I didn't have Mips board. I compile as the commands and check the asm output as below.
1. Question:
The distance of caller arg[4] and arg[5] is 4 bytes. But the the callee get every
arg[] by 8 bytes offset (arg_ptr1+8 or arg_ptr2+8). I assume the #BB#4 and #BB#5 are the arg_ptr which is the pointer to access the stack arguments.
2. Question:
Stack memory 28($sp) has no initial value. If
2013 Feb 20
0
[LLVMdev] Is va_arg correct on Mips backend?
Does it make a difference if you give the "-target" option to clang?
$ clang -target mips-linux-gnu ch8_3.cpp -o ch8_3.bc -emit-llvm -c
The .s file generated this way looks quite different from the one in your
email.
On Tue, Feb 19, 2013 at 5:06 PM, Jonathan <gamma_chen at yahoo.com.tw> wrote:
> I didn't have Mips board. I compile as the commands and check the asm
>
2010 Nov 17
0
[LLVMdev] L->isLoopInvariant giving wrong results?
i am getting seg fault on functions like I->eraseFromParent also.
I'm assuming that the problem comes when i change the loop structure.
On Thu, Nov 18, 2010 at 4:05 AM, Sreeraj a <writetosrj at gmail.com> wrote:
> The funny thing is that i am manually able to hoist the Loop invariant
> instruction to the basicBlock terminator, by editing the human readable form
> and then
2010 Nov 17
2
[LLVMdev] L->isLoopInvariant giving wrong results?
The funny thing is that i am manually able to hoist the Loop invariant
instruction to the basicBlock terminator, by editing the human readable form
and then using llvm-as to convert it into bytecode.
On Thu, Nov 18, 2010 at 4:01 AM, Chris Lattner <clattner at apple.com> wrote:
>
> On Nov 17, 2010, at 1:38 PM, Sreeraj a wrote:
>
> > Thanks Chris,
> >
> > I was
2013 Feb 19
0
[LLVMdev] Is va_arg correct on Mips backend?
Which part of the generated code do you think is not correct? Could you be
more specific?
I compiled this program with clang and ran it on a mips board. It returns
the expected result (21).
On Tue, Feb 19, 2013 at 4:15 AM, Jonathan <gamma_chen at yahoo.com.tw> wrote:
> I check the Mips backend for the following C code fragment compile result.
> It seems not correct. Is it my
2013 Feb 19
2
[LLVMdev] Is va_arg correct on Mips backend?
I check the Mips backend for the following C code fragment compile result. It seems not correct. Is it my misunderstand or it's a bug.
//ch8_3.cpp
#include <stdarg.h>
int sum_i(int amount, ...)
{
int i = 0;
int val = 0;
int sum = 0;
va_list vl;
va_start(vl, amount);
for (i = 0; i < amount; i++)
{
val = va_arg(vl, int);
sum += val;
}
va_end(vl);
2008 Oct 30
2
[LLVMdev] Target description flags for instructions which may trap
What are the correct target description side effect flags for
instructions which may trap (e.g. divide / remainder)? The divide
instruction in my backend currently has no flags set. I've enabled the
MachineLICM pass and it's causing a miscompilation by hoisting a divide
by zero instruction out of the loop. Clearly this pass needs to be made
aware that this is not safe. The current
2014 May 10
6
[LLVMdev] Replacing Platform Specific IR Codes with Generic Implementation and Introducing Macro Facilities
On 10 May 2014, at 13:53, Tim Northover <t.p.northover at gmail.com> wrote:
> It doesn't make sense for everything though, particularly if you want
> target-specific IR to simply not exist. What would you map ARM's
> "ldrex" to on x86?
This isn't a great example. Having load-linked / store-conditional in the IR would make a number of transforms related to
2008 Jul 06
2
[LLVMdev] Odd problem with command line options
Jay Foad wrote:
>> I'm linking a program (my ellsif driver) that basically brings in most
>> of the LLVM stuff: bitcode reading, optimizations, linking, and target
>> code generation.
>>
>> All of a sudden, I'm getting the following when I run:
>> [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i test/sieve.i -time-actions
>> -O5
>>
2010 Nov 17
1
[LLVMdev] L->isLoopInvariant giving wrong results?
my changed code.
namespace {
class MyLoopPass:public LoopPass {
bool changed;
public:
static char ID;
Loop* curLoop;
// AnalysisType* AA;
DominatorTree* DT;
LoopInfo* LI;
MyLoopPass() : LoopPass(ID){}
bool isLoopInvariantInst(Instruction &I) ;
bool runOnLoop(Loop * L, LPPassManager &lpm);
virtual void getAnalysisUsage(AnalysisUsage &AU) const {
2011 Jul 06
0
[LLVMdev] code generation removes duplicated instructions
On 6 July 2011 02:31, D S Khudia <daya.khudia at gmail.com> wrote:
> %0 = load i32* %i, align 4
> %HV14_ = getelementptr inbounds [100 x i32]* %a, i32 0, i32 %0
> %1 = getelementptr inbounds [100 x i32]* %a, i32 0, i32 %0
> %HVCmp7 = icmp ne i32* %1, %HV14_
> br i1 %HVCmp7, label %relExit, label %bb.split
>
> So that HV14_ is a new instruction and I am
2012 Jun 12
2
[LLVMdev] How to use LLVM optimizations with clang
Thanks again.
I executed the following command line
llc -O3 comb.ll.bc -debug-pass=Arguments
and got
Pass Arguments: -targetdata -targetpassconfig -no-aa -tbaa
-targetlibinfo -basicaa -collector-metadata -machinemoduleinfo
-machine-branch-prob -preverify -domtree -verify -loops -loop-simplify
-scalar-evolution -loop-simplify -iv-users -loop-reduce -gc-lowering
-unreachableblockelim
2011 Jul 06
2
[LLVMdev] code generation removes duplicated instructions
Hello,
I am duplicating few instructions in a basic block and splitting it. The
following is an example.
bb: ; preds = %bb1
%0 = load i32* %i, align 4
%1 = getelementptr inbounds [100 x i32]* %a, i32 0, i32 %0
store i32 0, i32* %1, align 4
%2 = load i32* %i, align 4
%3 = getelementptr inbounds [100 x i32]* %last_added, i32 0, i32 %2
store
2015 Jan 17
3
[LLVMdev] loop multiversioning
Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3
-mllvm -debug-pass=Arguments program.c -c
bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c
clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this
behavior is deprecated
Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa
-tbaa -scoped-noalias