similar to: [LLVMdev] "-relocation-model=static" does not work in llc compiler ?

> 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

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

Hi Pengcheng, > When I compile code using llc with options " -relocation-model=static", the generated code still has > relative addressing using *rip* frame pointer. May I know how to get rid of frame pointer and totally > using absolute addressing ? > > E.g. > callq *addr(%rip). > Here *addr* is a global variable, and I want the global address shows up here,

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

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

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

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.

Hi, This is a proposal to introduce a mechanism to LLVM that uses runtime instrumentation to verify that a call target preserves all of the registers it says it does. Internally, we have a diverse set of calling conventions for runtime functions that get called from LLVM compiled code, and having some sort of validation mechanism will give us more confidence in selecting aggressive calling

Hi There, I am currently exploring C++ JIT-compilation for a project where this would be very useful. I started with the code from the lli tool which uses OrcLazyJIT and changed it, such that the module is being compiled from c++ source in memory and OrcLazyJIT is used exclusively. Now since I am on windows, I found that my application is crashing when trying to run the main function from 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, I have seen and heard many cases of ext3 corrupted after abnormal powerdown (e.g. missing all the files in one directory). yes, UPS should help, but wonder what kind of worst scenario will ext3 present after powerdown. messed up meta data has been seen in many cases, for example, the in-direct block of one inode contains garbage, which causes the automatic fsck failed to work and user has

Hi David, This is really cool. I'd love to get this in-tree. There are two ways we could go about this: (1) Make the OrcArchitecture interface ABI-aware so that it can choose the right resolver code, or (2) Replace the OrcArchitecture classes with OrcABI classes. I.e. We'd just a rename OrcX86_64 -> Orc_X86_64_SysV (and rename I386 & AArch64 similarly) , then we add your code as

------------------------------------ IR ------------------------------------------------------------------ if.then.i.i.i.i.i.i: ; preds = %if.then4 %S25_D = zext <2 x i32> %splatLDS17_D.splat to <2 x i64> %umul_with_overflow.i.iS26_D = shl <2 x i64> %S25_D, <i64 3, i64 3> %extumul_with_overflow.i.iS26_D = extractelement <2 x i64>

Hi Mehdi, After deeper debug, I found my firmware LTO wrong code issue is related to X64 code model (-mcmodel=large) is always overridden as small (-mcmodel=small) if LTO build. And I don't know how to correctly specific the large code model for my X64 firmware LTO build. Appreciate if you could let me know it. You know, parts of my Uefi firmware (BIOS) have to been loaded to run in high

This snippet of IR is interesting: %sub.ptr.div.iS37_D = sdiv <2 x i64> %sub.ptr.sub.iS36_D, <i64 24, i64 24> %cmp10S38_D = icmp ugt <2 x i64> %sub.ptr.div.iS37_D, %splatInsMapS1_D.splat %zextS39_D = sext <2 x i1> %cmp10S38_D to <2 x i64> %BCS39_D = bitcast <2 x i64> %zextS39_D to i128 %mskS39_D = icmp ne i128 %BCS39_D, 0 br i1 %mskS39_D,

Hi Mehdi, GCC LTO seems support large code model in my side as below, if the code model is linker specific, does the GCC LTO use a special linker which is different from the one in GNU Binutils? I'm a bit surprised if both OS X ld64 and gold plugin do not support large code model in LTO. Since modern system widely use the 64bit, the code need to run in high address (larger than 2 GB) is a

Hi, > On May 29, 2016, at 7:36 AM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > After deeper debug, I found my firmware LTO wrong code issue is related to X64 code model (-mcmodel=large) is always overridden as small (-mcmodel=small) if LTO build. And I don't know how to correctly specific the large code model for my X64 firmware LTO build. Appreciate if

> On May 29, 2016, at 5:10 PM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > GCC LTO seems support large code model in my side as below, if the code model is linker specific, does the GCC LTO use a special linker which is different from the one in GNU Binutils? I don't know anything about GCC. (And I doubt the GNU linker supports LTO with LLVM). > I’m a