search for: inline_asm

...chine Verifier complains saying: *** Bad machine code: Using an undefined physical register *** - function: main - basic block: BB#238 for.inc.121.4 (0x43133b0) - instruction: PUSHF64- operand 2: %EFLAGS<imp-use,kill> Anyway right now i'm able to push it via some "dirty" INLINE_ASM. 2) INLINE_ASM works pretty well, except in one randomly generated test case where the register allocator spills a register in between the pushfq/popfq, resulting in a crash of the compiled application. So the question is: is there a recommended way to save and restore the value of eflags? Any h...

...L -fPIC -static -o constraints.exe constraints.o the inline-asm is: #APP lw $5, 0($1) #NO_APP #APP lw $5, 0($1) #NO_APP #APP lwl $5, 1 + 0($1) lwr $5, 2 + 0($1) #NO_APP It use different registers, but $1, that is $AT, cann't be used, it is reserved for $AS using. any ideas? > inline_asm: run *.exe > out is 4 > out is 10 > out is ccddffbb > inline_asm: > Regards, Jia

...lw $5, 0($1) > #NO_APP > > #APP > lw $5, 0($1) > #NO_APP > > #APP > lwl $5, 1 + 0($1) > lwr $5, 2 + 0($1) > #NO_APP > > It use different registers, but $1, that is $AT, cann't be used, it is > reserved for $AS using. > any ideas? > >> inline_asm: run *.exe >> out is 4 >> out is 10 >> out is ccddffbb >> inline_asm: >> > > Regards, > Jia >

...tant input operands (needed for the asm-printer). > > Not sure if this is of any help. > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation I've had some luck with this. It turns out that the ISD::INLINE_ASM node has a flag operand corresponding to each operand in the source code. It's used for storing things like the matched operand number for the [0-9]+ constraints, the register class id for register constraints, etc. At first glance, the encoding looks full but it appears that when the lowest 3...

...n rewrite it. > Could this patch ever break in cases where the > operand's vreg doesn't happen to get mapped to ST0? Yes, exactly. You need to make some more complicated test cases. > I'm still a bit > foggy on the internals of X86FloatingPoint. Look at the code handling INLINE_ASM. You need to do the same, except you have fixed arguments STUses=1 and STClobbers=1, ST*=0. That should greatly simplify the code you need. > One thing I noticed is that fptosi and fptoui both seem to always emit > a redundant SSE load/store when SSE is enabled, because of the check > at...

...n't expand the instruction right away in EmitInstrWithCustomInserter(), and leaving the pseudo and call instructions side by side is not going to work. > > Just leave the pseudo-instruction alone until it hits X86FloatingPoint, where you can rewrite it. > > Look at the code handling INLINE_ASM. You need to do the same, except you have fixed arguments STUses=1 and STClobbers=1, ST*=0. That should greatly simplify the code you need. That makes sense; thanks for the tip. Are the getCopyToReg(ST0) and addReg(ST0, ImplicitKill) calls on the expanded MI at all necessary then since X86Floating...

On Fri, Jan 20, 2012 at 2:10 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > X86FloatingPoint.cpp with comments is all you get. Thanks for your help, Jakob. Attached is a first-pass attempt at a patch. I don't want to post to -commits yet because I have no idea if this is fully correct, but it seems to work in simple test cases. Am I on the right track? Could this patch ever

On Jan 20, 2012, at 1:58 PM, Joe Groff wrote: > The integer runtime functions (_allmul, _alldiv, etc. for 64-bit > integer arithmetic) all appear to be straight-up stdcall. _ftol2 is > the only weird one. (There is an _ftol routine with the same calling > convention as _ftol2, but AFAIK it's only for backward compatibility > with older MSVC runtimes.) I'm far from an MSVC

...pragma section [ section-type][ new-section-name] section-type:{text|const|data|bss} #pragma inline [(]function-name [,...][)] #pragma noinline [(]function-name [,...][)] As the name says inline, noinline. We have inline, __inline and __inline__ keywords and __attribute__ ((always_inline)). #pragma inline_asm [(]function-name [,...][)] This pragma specifies the body of the function is assembly code. I image substantial changes will be required in clang for this. #pragma address [(]variable-name=absolute-address[,...][)] This can be implemented with __attribute((section("section-name")) and the...

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Krzysztof Parzyszek > Sent: 03 March 2015 14:35 > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Inline Assembly: Memory constraints with offsets > > On 3/3/2015 6:01 AM, Daniel Sanders wrote: > > Hi, > > > > I'm trying to

...pragma section [ section-type][ new-section-name] section-type:{text|const|data|bss} #pragma inline [(]function-name [,...][)] #pragma noinline [(]function-name [,...][)] As the name says inline, noinline. We have inline, __inline and __inline__ keywords and __attribute__ ((always_inline)). #pragma inline_asm [(]function-name [,...][)] This pragma specifies the body of the function is assembly code. I image substantial changes will be required in clang for this. #pragma address [(]variable-name=absolute-address[,...][)] This can be implemented with __attribute((section("section-name")) and the...

...pragma section [ section-type][ new-section-name] section-type:{text|const|data|bss} #pragma inline [(]function-name [,...][)] #pragma noinline [(]function-name [,...][)] As the name says inline, noinline. We have inline, __inline and __inline__ keywords and __attribute__ ((always_inline)). #pragma inline_asm [(]function-name [,...][)] This pragma specifies the body of the function is assembly code. I image substantial changes will be required in clang for this. #pragma address [(]variable-name=absolute-address[,...][)] This can be implemented with __attribute((section("section-name")) and the...