similar to: [LLVMdev] External constants and RIP relative addressing

Chris, > You'll have to hack up the code generator, there is no user visible knob to turn off rip relative addressing. Why? One can use medium code model which does not do any rip-rel stuff. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On May 16, 2011, at 6:24 AM, Chris Stavrakakis wrote: > Hi all, > > in llvm-2.8, i declare an external constant of i64 and i want the > instructions that use the value of this constant to use absolute > addressing instead of RIP relative, that is: > > I get: "48 8b 35 00 00 00 00 mov 0x0(%rip),%rsi" #AT&T syntax > But i would prefer: "48 BE

Hi all, in llvm-2.8, i declare an external constant of i64 and i want the instructions that use the value of this constant to use absolute addressing instead of RIP relative, that is: I get: "48 8b 35 00 00 00 00 mov 0x0(%rip),%rsi" #AT&T syntax But i would prefer: "48 BE 00 00 00 00 00 00 mov 0x0, %rsi" The reason i want this is that i use a specific

With LLVM 2.7 is there an easy way to turn off RIP-relative addressing? I'm debugging an issue here and turning off RIP-relative addressing would greatly reduce the number of diffs I have to pour through. Thanks! -Dave

Thanks for your reply. I have a normal (../configure --enable-profiling --disable-optimized --enable-assertions) llvm debug+profile+assert build. I am generating llvm-bitcode using following commands. llvm-gcc -DLINUX_i386 -DSPEC_CPU2000 -O3 -emit-llvm 186.crafty/src/valid.c -c -o 186.crafty/src/valid.bc --- llvm-link 186.crafty/src/*.bc -o 186.crafty/186.crafty.rel.bc and finally: llc

Hi all, Continuing work on llvm-ml (a MASM assembler)... and my latest obstacle is in enabling MASM's convention that (unless specified) all memory location references should be RIP-relative. Without it, we emit the wrong instructions for "call", "jmp", etc., and anything we build fails at the linking stage. My best attempt at this so far is a small patch to

Apologies - I apparently remembered part of the issue incorrectly, so this ended up quite confusing. The problem comes when referencing labels in a different section of the binary. To clarify, if I assemble the code: .data foo BYTE 5 .code mov eax, foo with Microsoft's ml64.exe, it emits an object file disassembling to: 0: 8b 05 00 00 00 00 mov eax, dword ptr [rip]

Hello > Command => llc -march=arm 186.crafty/186.crafty.rel.bc -o > 186.crafty/186.crafty.m5arm.s > Error =>  LLVM ERROR: Couldn't allocate output reg for constraint '{cx}'! > > Have anyone seen this before? It seems you're feeding x86-specific LLVM IR to arm backend. Please don't do that. -- With best regards, Anton Korobeynikov Faculty of Mathematics

Are you asking what the parsing rules are, or how you should modify the LLVM code to achieve that result? If the latter, you haven’t really given enough detail here. What code, exactly, have you tried modifying? Do you have any ideas for how it could work? -Eli From: Eric Astor <epastor at google.com> Sent: Tuesday, January 21, 2020 2:44 PM To: Eli Friedman <efriedma at

oh,I'm sorry to make such a stupid mistake...But I still have to tell the correct one still didnt make difference...so weird 2014-04-04 16:30 GMT+08:00 Anton Korobeynikov <anton at korobeynikov.info>: > Are you sure, that LLVMGetNamedFunction(m,"_a_outside_func") does not > return NULL? I believe it should be > LLVMGetNamedFunction(m,"a_outside_func") >

Peter, Thanks for the great feedback! > The first is the use of a custom suffix, all other linker conventions, that I know of, use prefixes as these are much easier and faster to match against names. > This can be important in large programs compiled -ffunction-sections as there can be millions of sections to match. I understand the reason of having these conventions in linkers. On the

HI, Dear Greg, I have one question about the variable relative influence plot: THE following is the rel.inf value of 25 variables, but wen I plot, not all the variables are labeled. i.e. num_genes, wg, hydrophob_per etc are not labeled on the y-axis. also the variables are labeled vertically, can it be labeled horizontally just like the summary table? Thanks! > summary(gbm1,

Hello, Bram. > My question: does this change break certain design decisions, > optimisations, ...? This is bug in the source code. You have two symbols with the same name in the different object files, which is definite redefinition. At least one of them should be declared with "extern". -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint

Should be there On Fri, Nov 16, 2012 at 3:00 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Anton, please add release_32 also in; > > clang-tools-extra > compiler-rt > dragonegg > libcxxabi > lldb > > They have release_32 in svn. I don't know they might be released, though. > > And, could you suppress generating refs/heads/svn-tags and prune them

Hello, Bill > Comments? I don't personally like this patch. It seems, that emitted data encoding is linker (=subtarget) specific. For example, gcc uses three different data encodings to emit dwarf data on darwin. I think we should introduce subtarget hooks for encoding selection of data being emitted (there is already one: needSet / *AbsoluteOffsets etc). Also "generic" function

The destination register and each of the source registers can be relatively addressed by some special "address registers": a0, a1, a2, a3. suppose a0 = 4, a1 = 2, the instruction add r[a0], r[a1], r7 equals to: r4 = r2 + r7 How should the instruction be defined in TableGen *.td file? If an opcode is defined for each variant (like X86InstrInfo.td) there will be eight opcodes

Hi, Thanks for pointing direction. As far, as I understand by reversing, logic, that I want to overwrite is digged into: lib/MC/MCSectionELF.cpp MCSectionELF::PrintSwitchToSection if (ShouldOmitSectionDirective(SectionName, MAI)) { OS << '\t' << getSectionName() << '\n'; return; } // otherwise print ".section" directive and then section

>>> Any help will be much appreciated. Thanks! >> Windows does not support dynamic linking. You will need to resolve >> externals by hand. > > Why would it not support dynamic linking?  What about loadlibrary and > its kin are not sufficient to handle this? Well, you cannot easily export stuff from an executable and this is the main issue here. (And you cannot e.g.

Hello I quite thank you for your advice,but I have to tell that it made no difference too calling "LLVMAddGlobalMapping(ee,LLVMGetNamedFunction(m,"_a_outside_func"),(void*)(&a_outside_func));". 2014-04-04 16:10 GMT+08:00 Anton Korobeynikov <anton at korobeynikov.info>: > Hello > > While there is a symbol in the object file, there is nothing like this >

Is that really sufficient? See X86ISelLowering.cpp, look for addLegalFPImmediate. Usually targets have to tell legalizer what fp immediates are legl. Evan On Jan 5, 2010, at 8:38 AM, Anton Korobeynikov wrote: > Hello > >> I was wondering if it is possible to stop floating-point constants being converted to use the constant pool? As for our back-end we would like to be able to treat