search for: no_app

....ll -o constraints.llc.s -mcpu=mips32r2 -march=mipsel -filetype=asm llvm-install/bin/llc constraints.ll -o constraints.o -mcpu=mips32r2 -march=mipsel -filetype=obj mipsel-unknown-linux-gnu-gcc -mips32r2 -O3 -EL -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: > Re...

...9 @@ public: case 'x': // hilo register pair Info.setAllowsRegister(); return true; + case 'R': // An address that can be used in a non-macro load or store + Info.setAllowsMemory(); + return true; } } Clang gen asm frag: #APP lw $2, 0($2) #NO_APP #APP lw $1, 0($1) #NO_APP #APP lwl $1, 1 + 0($1) lwr $1, 2 + 0($1) #NO_APP gcc gen asm frag: #APP # 12 "constraints.c" 1 lw $16, 0($2) # 0 "" 2 #NO_APP #APP # 20 "constraints.c" 1 lw $16, 0($2) # 0 "" 2 #NO_APP #APP # 28 "constraints.c...

...ch=mipsel -filetype=asm > llvm-install/bin/llc constraints.ll -o constraints.o -mcpu=mips32r2 > -march=mipsel -filetype=obj > mipsel-unknown-linux-gnu-gcc -mips32r2 -O3 -EL -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 >&...

...uot; I think the underlying issue here is that whichever variant of Intel syntax this supports (MASM?) treats mov reg, symbol as a load and it wants mov reg, offset symbol E.g., if I ask Clang to output assembly in Intel syntax via -mllvm --x86-asm-syntax=intel, I get #APP mov eax, offset foo #NO_APP #APP mov ebx, dword ptr [bar] #NO_APP (I have no idea where those extra newlines are coming from.) If I try to change the assembly template to "mov ebx, offset $0" it complains about multiple symbols being present: <inline asm>:2:18: error: cannot use more than one symbol in...

...no-op in the .bc file. However, llc then moves the volatile no-op below the multiply. tail call void asm sideeffect "NOP", ""() nounwind %2 = mul nsw i32 %y, %x tail call void asm sideeffect "NOP", ""() nounwind becomes.... mul r12, r12, r0 ... @APP NOP @NO_APP @APP NOP @NO_APP Andrew Lukefahr andrewlukefahr at gmail.com Open Source, Open Minds On Mon, Dec 6, 2010 at 2:08 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Dec 6, 2010, at 10:57 AM, John Criswell wrote: > > > On 12/6/10 11:39 AM, Andrew Lukefahr wrote: > &g...

On Dec 6, 2010, at 10:57 AM, John Criswell wrote: > On 12/6/10 11:39 AM, Andrew Lukefahr wrote: >> Hi, >> >> How would I disable dead code elimination in llc? Can that be done via the command line or do I need to modify llc's source? > > You can use llc --help-hidden to see a list of options. There are several -disable-xxx options that disable various code

...of Intel syntax this supports (MASM?) treats > mov reg, symbol > as a load and it wants > mov reg, offset symbol > > E.g., if I ask Clang to output assembly in Intel syntax via -mllvm --x86-asm-syntax=intel, I get > #APP > mov eax, offset foo > #NO_APP > #APP > > mov ebx, dword ptr [bar] > > #NO_APP > > (I have no idea where those extra newlines are coming from.) > > If I try to change the assembly template to "mov ebx, offset $0" it complains about multiple symbols being presen...

...be a happy coincidence. I've read that too in the docs but I don't think it has any meaning here because I'm emitting the same kind of code that gcc emits; so I should not need them. Possible it slows down compilation by some tiny amount here. It does not hurt for me to have the APP/NO_APP markers; I just don't like to see them in the .s file. As Jim Grosbach and others have noted, if I move the inline asm generation to another place, I won't get those. It's just because the compiler is doing what I user would do that I'm getting them. -------------- next part -...

...------------------ .file "lolwut.bc" .text .globl lolwut .align 2 .type lolwut,%function lolwut: @ @lolwut .fnstart @ BB#0: @ %entry @APP ldr r1, .Ltmp0 .align 2 .Ltmp0: .long ".L11" ".L11": @NO_APP bx lr .Ltmp1: .size lolwut, .Ltmp1-lolwut ------------------------------------------ Somehow, the forward referenced label at 1: in the original assembly is getting mangled when its constant pool entry is created (the bad character is a 0x02 hex). In previous versions, the inline assembly was...

...t; I've read that too in the docs but I don't think it has any meaning here > because I'm emitting the same kind of code that gcc emits; so I should not > need them. Possible it slows down compilation by some > tiny amount here. > > It does not hurt for me to have the APP/NO_APP markers; I just don't like to > see them in the .s file. > As Jim Grosbach and others have noted, if I move the inline asm generation > to another place, I won't get those. It's just because the compiler is doing > what I user would do that I'm getting them. > I woul...

...oo .p2align 4, 0x90 .type foo, at function foo: # @foo # BB#0: # %entry pushl %ebp movl %esp, %ebp #APP named_label_0: jne named_label_0 #NO_APP popl %ebp retl .Lfunc_end0: .size foo, .Lfunc_end0-foo .globl bar .p2align 4, 0x90 .type bar, at function bar: # @bar # BB#0: # %entry pushl...

...t too in the docs but I don't think it has any meaning here >> because I'm emitting the same kind of code that gcc emits; so I should not >> need them. Possible it slows down compilation by some >> tiny amount here. >> >> It does not hurt for me to have the APP/NO_APP markers; I just don't like to >> see them in the .s file. >> As Jim Grosbach and others have noted, if I move the inline asm generation >> to another place, I won't get those. It's just because the compiler is doing >> what I user would do that I'm getting th...

from https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html Under certain circumstances, GCC may duplicate (or remove duplicates of) > your assembly code when optimizing. This can lead to unexpected duplicate > symbol errors during compilation if your asm code defines symbols or > labels. Using ‘%=’ (see AssemblerTemplate) may help resolve this problem. ‘%=’ > Outputs a number that is

...ilgamesh: ~/tmp $ clang -target arm-linux-eabi -S -Os foo.c -o - .syntax unified .eabi_attribute 20, 1 .eabi_attribute 21, 1 .eabi_attribute 23, 3 .eabi_attribute 24, 1 .eabi_attribute 25, 1 .file "foo.c" .text .globl foo .align 2 .type foo,%function foo: @APP push {r4} @NO_APP bx lr .Ltmp0: .size foo, .Ltmp0-foo On Jul 11, 2012, at 1:44 AM, Moshe Kravchik wrote: > Hi, > > I encountered an issue with inline assembly in my c files compiled with llvmc. > > When I have a push instruction in the inline assembly like: > > __asm__ volatile ( >...

...le, I get #APP # 164 "./arch/x86/include/asm/cpufeature.h" 1 STATIC_CPU_HAS bitnum=$8 cap_byte="boot_cpu_data+35(%rip)" feature=123 t_yes=.L75 t_no=.L78 always=117 #, MEM[(const char *)&boot_cpu_data + 35B],,,, # 0 "" 2 .loc 11 164 2 view .LVU480 #NO_APP but I'd like to see the actual asm as it is really helpful when hacking on inline asm stuff. And I haven't found a way to make gcc expand asm macros in .s output. Now, assuming the gcc inline patch will be backported to gcc8, I think we should be covered on all modern distros going forwar...

On Mon, May 6, 2013 at 9:09 AM, reed kotler <rkotler at mips.com> wrote: > On 05/06/2013 08:51 AM, Rafael Espíndola wrote: > >> It's working fine just that it's ugly to see those APP/NOAPP markers. >>> >> Inline assembly is inline assembly. It has the semantics defined in >> the IL documentation and should all be treated uniformly. >> >>

Hi, I encountered an issue with inline assembly in my c files compiled with llvmc. When I have a push instruction in the inline assembly like: __asm__ volatile ( "push {r4}\n\t" ); the compiler will drop the curly braces and leave it in the generated assembly file as: push r4 And this is non-conformant with the ARM

Hi Jim, There is no "target independent" code in these patches. It's all Mips specific. There is something I'm proposing for AP/NO_APP wrappers but that will just make the stubs look nicer (without the clutter of those wrappers). That is purely a cosmetic issue of the .s files being produced. The discussion has moved back to the main thread so I'll continue there. Thanks for taking to make a detailed answer. Reed On 05/1...

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the

On Wed, Oct 10, 2018 at 01:54:33PM -0500, Segher Boessenkool wrote: > It would be great to hear from kernel people if it works adequately for > what you guys want it for :-) Sure, ping me when you have the final version and I'll try to build gcc with it and do some size comparisons. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the