similar to: [LLVMdev] Addresses about Label or baiscblock

What do you mean by test case please ? Using the following commands to compile mcf program can reproduce such issue all the time. Probably it is my version's problem. Because I checked out 3.3version from SVN before published. Could you tell me where Manman modified ? I cannot port to new version very quickly after changing it a lot already. Thanks, - Pengcheng On Nov 5, 2013, at

Hi, What version of clang are you using? I think r174785 is the fix. Manman On Tue, Nov 5, 2013 at 11:04 AM, lipengcheng <pli at cs.rochester.edu> wrote: > What do you mean by test case please ? Using the following commands to > compile mcf program > can reproduce such issue all the time. > > Probably it is my version's problem. Because I checked out 3.3version from

Also r174479. Manman On Tue, Nov 5, 2013 at 11:11 AM, Manman Ren <manman.ren at gmail.com> wrote: > Hi, > > What version of clang are you using? I think r174785 is the fix. > > Manman > > > On Tue, Nov 5, 2013 at 11:04 AM, lipengcheng <pli at cs.rochester.edu> wrote: > >> What do you mean by test case please ? Using the following commands to

Another finding is when I use both -code-model=large and -relocation-model=pic (!!!!!note changed), it still generate the static relocation. So does it mean -relocation-model=pic does not like to work with -code-model=large ? Thanks, -Pengcheng On Nov 6, 2013, at 1:52 PM, lipengcheng <pli at cs.rochester.edu> wrote: > Yep. I tried it. It used a movabsq instruction instead and a

This is from work that Manman did. I thought she'd fixed this particular issue though. Can you file a bug with a test case please? On Nov 5, 2013 10:10 AM, "lipengcheng" <pli at cs.rochester.edu> wrote: > Hello LLVM, > > I encountered the following bugs when I compiled my program in debug > version. > Could someone help me with that ? Really appreciate that.

Hello LLVM, I encountered the following bugs when I compiled my program in debug version. Could someone help me with that ? Really appreciate that. Thanks, Take the mcf program in SPEC2K6 as example. The compiling options are : clang -O0 -c -emit-llvm -o obj/mcf.o -g -DSPEC_CPU mcf.c llvm-link -o mcf.bc obj/mcf.o opt -o mcf.opt.bc mcf.bc -O2 llc -O0 -relocation-model=static -o mcf.s

Yep. I tried it. It used a movabsq instruction instead and a static allocation. Thanks a lot. I will read it immediately. Again thanks. - Pengcheng On Nov 6, 2013, at 1:45 PM, Tim Northover <t.p.northover at gmail.com> wrote: >> If you also give "-code-model=large" then LLVM won't assume that >> "addr" is nearby so it'll use a movabsq with a

> If you also give "-code-model=large" then LLVM won't assume that > "addr" is nearby so it'll use a movabsq with a static relocation. Actually, it seems our own Eli has written rather a good description of these code models: http://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models/. Well worth the read (the default models he talks about at the

Dear all, When I use parallel function in lattice package, I want to label the y-axis with customized numbers. Like this: parallel(~iris[1:4] | Species, iris,horiz=FALSE,common.scale=TRUE, scales=list(y=list(at=c(0,2,3)))) But only "Min" label in the y-axis, nothing happened. Could anyone help me? Thanks. Regards, Pengcheng Yang

Hi everyone I'm hitting an assertion in PHIElimination.cpp:375. "Terminator instructions cannot use virtual registers unless" "they are the first terminator in a block!" I was looking at the code around that location a bit and have not found a reason why this assertion has to hold, except for a comment: // In our final twist, we have to decide which instruction

Ok, after a long detour I am back to where I have started. I think there is a problem at dep DAG construction. Let me try to convince you. Here is the C code we are dealing with: push () { struct xx_stack *stack, *top; for (stack = xx_stack; stack; stack = stack->next) top = stack; yy_instr = top->first; } If the loop never iterates, "top" will have

Sergei, Absolutely right, the copy/ldriw should not be reordered. I was attempting to explain that I consider it a phi-elimination bug, not a DAG builder bug. Liveness will also have problems with this code in the long run. To avoid confusion, I filed PR13112: Phi elimination generates uninitialized vreg uses, and disabled the SSA check until its fixes in r158461. However, your C code is also

Andy, You are probably right here - look at this - before phi elimination this code looks much more sane: # *** IR Dump After Live Variable Analysis ***: # Machine code for function push: SSA Function Live Outs: %R0 BB#0: derived from LLVM BB %entry %vreg5<def> = IMPLICIT_DEF; IntRegs:%vreg5 %vreg4<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg4

Hello Has there been any progress on this topic ? The 3.9 optimizer output is still the same as I just looked. https://llvm.org/bugs/show_bug.cgi?id=24448 Ciao Nat! Sanjay Patel schrieb: > [cc'ing Zia] > > We have this transform with -Os for some cases after: > http://reviews.llvm.org/rL244601 > http://reviews.llvm.org/D11363 > > but something in this example is

On Jun 13, 2012, at 1:15 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, > > You are probably right here – look at this – before phi elimination this code looks much more sane: > > # *** IR Dump After Live Variable Analysis ***: > # Machine code for function push: SSA > Function Live Outs: %R0 > > BB#0: derived from LLVM BB %entry >

...this is moving from llvm-commits to llvm-dev. On Feb 10, 2012, at 12:14 PM, Sergei Larin <slarin at codeaurora.org> wrote: > 1) Can a BB presented to the MI scheduler be _not_ terminated (end on a non > terminator MI) under any circumstances? Below you are speaking about "Empty > blocks, or blocks with only a single instruction that not a terminator..." - > What

This implements the label completion on tab key idea. It does introduce "labelcompl" as new config keyword. The default value is 0 so it does not change current behaviour. If you press tab with an empty command line it will display all labels. If the command line contains any characters it will display the matching labels. This patch is only intended for testing since i didn't check

Hi the appended IR code does not optimize to my liking :) this is the interesting part in x86_64, that got produced via clang -Os: --- movq -16(%r12), %rax movl -4(%rax), %ecx andl $2298949, %ecx ## imm = 0x231445 cmpq $2298949, (%rax,%rcx) ## imm = 0x231445 leaq 8(%rax,%rcx), %rax cmovneq %r15, %rax movl $2298949, %esi ## imm = 0x231445 movq %r12, %rdi movq %r14,

I changed the input C to using a 64 bit type for the loop index (this eliminates 'sext' instructions in the IR) Here the IR produced with clang -O0 define float @foo(i64 %start, i64 %end, float* %A) #0 { entry: %start.addr = alloca i64, align 8 %end.addr = alloca i64, align 8 %A.addr = alloca float*, align 8 %sum = alloca [4 x float], align 16 %i = alloca i64, align 8

.entry.text is a code area which is used for interrupt/syscall entries, and there are many sensitive codes. Thus, it is better to prohibit probing on all of such codes instead of a part of that. Since some symbols are already registered on kprobe blacklist, this also removes them from the blacklist. Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> Cc: Thomas Gleixner