search for: clobbers

Hi guys, I think I have run into another CachingMemorySSAWalker cache bug. It's a bit tricky to reproduce, so I'd like to start by trying to show you what is happening when running EarlyCSE with my local changes to use MemorySSA. I've attached a debug log that shows that the value returned by getClobberingMemoryAccess(Inst) after a call to removeMemoryAccess is wrong. The

There is no need any longer to store the clobbers in struct paravirt_patch_site. Remove clobbers from the struct and from the related macros. While at it fix some lines longer than 80 characters. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/include/asm/paravirt.h | 33 +++++++++++++++------------------ arch/x86/inc...

...include/asm/paravirt-asm.h b/arch/x86/include/asm/paravirt-asm.h index add8a190fdac..8bdd50ee4bf3 100644 --- a/arch/x86/include/asm/paravirt-asm.h +++ b/arch/x86/include/asm/paravirt-asm.h @@ -7,16 +7,18 @@ #include <asm/asm.h> #include <asm/paravirt_types.h> -#define _PVSITE(ptype, clobbers, ops, word, algn) \ -771:; \ - ops; \ -772:; \ - .pushsection .parainstructions,"a"; \ - .align algn; \ - word 771b; \ - .byte ptype; \ - .byte 772b-771b; \ - .short clobbers; \ +#define PV_TYPE(ops, off) ((PARAVIRT_PATCH_##ops + (off)) / __ASM_SEL(4, 8)) +...

In your sequences in asm/paravirt.h, you explicitly save the caller-save regs: static inline void raw_local_irq_restore(unsigned long f) { __asm__ __volatile__(paravirt_alt("pushl %%ecx; pushl %%edx\n\t" "pushl %1; call *%0\n\t" "popl %1; popl %%edx; popl %%ecx", PARAVIRT_RESTORE_FLAGS) : : "m" (paravirt_ops.restore_fl),

The clobbers parameter from paravirt_patch_default() et al isn't used any longer. Remove it. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/include/asm/paravirt_types.h | 7 +++---- arch/x86/kernel/alternative.c | 2 +- arch/x86/kernel/paravirt.c | 14 +++++------...

...000..add8a190fdac --- /dev/null +++ b/arch/x86/include/asm/paravirt-asm.h @@ -0,0 +1,126 @@ +#ifndef _ASM_X86_PARAVIRT_ASM_H +#define _ASM_X86_PARAVIRT_ASM_H + +#ifdef CONFIG_PARAVIRT +#ifdef __ASSEMBLY__ + +#include <asm/asm.h> +#include <asm/paravirt_types.h> + +#define _PVSITE(ptype, clobbers, ops, word, algn) \ +771:; \ + ops; \ +772:; \ + .pushsection .parainstructions,"a"; \ + .align algn; \ + word 771b; \ + .byte ptype; \ + .byte 772b-771b; \ + .short clobbers; \ + .popsection + + +#define COND_PUSH(set, mask, reg) \ + .if ((~(set)) &...

On 1/8/2013 3:52 PM, Eli Friedman wrote: > > From gcc docs: "If your assembler instructions access memory in an > unpredictable fashion, add `memory' to the list of clobbered > registers. This causes GCC to not keep memory values cached in > registers across the assembler instruction and not optimize stores or > loads to that memory. You also should add the volatile

Hi, I''ve started looking at ticket 90<http://merb.devjavu.com/projects/merb/ticket/90>and there are a couple of situations that the current implementation doesn''t cater for. 1. Tag Attributes are wiped out. - <tag1 attr1=''1''>Content</tag1> #=> { "tag1" => "Content" } - I think it should return -

Hi all, I'm tracking down a register allocation problem and I'm trying to understand this piece of code in InlineSpiller::spillAroundUses: // Find the slot index where this instruction reads and writes OldLI. // This is usually the def slot, except for tied early clobbers. SlotIndex Idx = LIS.getInstructionIndex(*MI).getRegSlot(); if (VNInfo *VNI = OldLI.getVNInfoAt(Idx.getRegSlot(true))) if (SlotIndex::isSameInstr(Idx, VNI->def)) Idx = VNI->def; Comments in SlotIndexes.h have this to say: /// Early-clobber register use/def slot....

Using Clang/LLVM 3.6.0 we are observing a case where the optimizations are clobbering EFLAGS on x86_64. This is inconvenient when the status of bit 9 (IF), which controls interrupts, changes. Here's a simple test program. Assume that the external function foo() modifies the IF bit in EFLAGS. --- #include <stdlib.h> #include <stdbool.h> void foo(void); int a; int bar(void)

On Oct 19, 2010, at 8:00 PM, Jakob Stoklund Olesen wrote: > > > One problem is that calling conventions are handled while building the selection DAG, and the DAG doesn't really know to represent clobbered registers. > > Perhaps X86TargetLowering::LowerCall() could decorate the X86ISD::CALL node with the calling convention somehow? > > Dan, do you have any thoughts on

Consider this program: --- asm.c --- int G; int foo(char *p) { int rv; G = 0; asm ("" : "=r"(rv) : "r"(p) : "memory"); return rv + G; } ------------- Is the use of "memory" clobber sufficient to expect the optimizer not to optimize the "+ G" away in the return statement? I'll add here that

Hello Clang and LLVM Devs, I have been working to add support for an attribute in clang and LLVM that helps user to guide interprocedural register allocation. But the use case I am having is very limited and thus I belieave it is good to have discussion on this before sending a patch. So for IPRA we have a situation where a function is calling a function which is written in assembly and it is

...VM tries to match register specified in constraint to register name of register definition in .td file but not to the AsmName for this register. For example if we have register definition: def MYReg0 : Register<"r0", 0>; We want to create inline assembly and add this register to clobbers list. Inline assembly should look something like this: i32 asm "nop", "~{r0}" () We used AsmName for register MYReg0 inside clobbers list. But this constraint fails to work because TargetLowering::getRegForInlineAsmConstraint() tries to match register definiti...

I remember this bug. :) IMO, LLVM should never emit pushf / popf. I'm not sure this patch to fix it ever got committed: http://reviews.llvm.org/D6629 On Wed, Jul 29, 2015 at 3:11 PM, Michael Hordijk <hoffbrinkle at hotmail.com> wrote: > > Using Clang/LLVM 3.6.0 we are observing a case where the optimizations are > clobbering EFLAGS on x86_64. This is inconvenient when the

On Tue, Jan 8, 2013 at 2:17 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 1/8/2013 3:52 PM, Eli Friedman wrote: >> >> >> From gcc docs: "If your assembler instructions access memory in an >> unpredictable fashion, add `memory' to the list of clobbered >> registers. This causes GCC to not keep memory values cached in >>

Hi All, I'm looking into this simple inline assembly code. Were we copy contents on data to eax,ebx,ecx and edx and later copy them back from the registers to data. Test Case - #include <stdio.h> int data[] = { 0x14131211, 0x24232221, 0x34333231, 0x44434241, }; int main (int argc, char **argv) { asm ("mov 0(%0), %%eax\n\t" "mov 4(%0), %%ebx\n\t"

...analyzed is: >>>> %BX<def> = MOV16rm %EDI, 2, %ECX, 0, %noreg; >>> mem:LD2[%arrayidx98](tbaa=!18) >>>> >>>> and the Reg being passed in is 21, which is EBX. The result I get back for >>> is: >>>> >>>> Analysis: {Clobbers = true, Defines = true, Reads = false, ReadsOverlap = >>> false, >>>> DefinesDead = false, Kills = false} >>>> >>>> It seems based on the comment in the definition of PhysRegInfo.Defines, >>> that Defines should only be true if Reg or a super-r...

...the instructions in the middle (ii): 1. A verbatim translation into an 'add' and a 'sub' instruction. I prefer this because it does not modify the flags in question. 2. The more idiomatic translation into 'negadd'. In this context, this translation is incorrect because it clobbers the flag and disrupts the data dependence from (i) to (iii). How can I specify that the second choice is incorrect in this instance because it clobbers the implicit flow. Thank you, Nick Johnson D. E. Shaw Research

...sn_string) \ - _paravirt_alt(insn_string, "%c[paravirt_typenum]", "%c[paravirt_clobber]") - /* Simple instruction patching code. */ #define NATIVE_LABEL(a,x,b) "\n" a #x "_" #b ":\n\t" @@ -388,13 +361,46 @@ unsigned native_patch(u8 type, u16 clobbers, void *ibuf, int paravirt_disable_iospace(void); + /* - * This generates an indirect call based on the operation type number. - * The type number, computed in PARAVIRT_PATCH, is derived from the - * offset into the paravirt_patch_template structure, and can therefore be - * freely converted b...