search for: clobbering

...k 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 MemorySSA node in question is MemoryUse(7), and the corruption happens after a call to remove MemoryUse(2), at which point its clobber value changes to '1 = MemoryDef(liveOnEntry)'. The interesting thing is that is doe...

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/include/asm/paravirt_types.h | 1 - 2 files changed,

Some cleanup to make the code easier to read and understand: - Use the common "PV_" prefix - Simplify the PV_SITE macro interface - Improve whitespace Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> --- arch/x86/include/asm/paravirt-asm.h | 95 +++++++++++++++++++------------------ 1 file changed, 49 insertions(+), 46 deletions(-) diff --git

...of making these registers are freely available for inlined code to use as temps, and making the register usage match the normal ABI calling convention. On the other hand, I suppose, if the inlined code doesn't need the registers, it is a waste to make gcc rearrange things. Assuming always clobbering ecx and edx would cause too much gcc reloading, it seems reasonable to me to say that any paravirt code sequence can use eax as input, output or scratch, and (say) ecx is also available for scratch. If it needs more (like a call to C function would), then it needs to save anything else it wants...

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 +++++--------- arch/x86/kernel/paravirt_patch_32.c | 5 ++---

The paravirt.h file is quite big and the asm interfaces for paravirt don't need to be in the same file as the C interfaces. Move the asm interfaces to a dedicated header file. Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> --- arch/x86/entry/entry_32.S | 1 + arch/x86/entry/entry_64.S | 2 +- arch/x86/entry/entry_64_compat.S | 1 +

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 =

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;...

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

Hi all, I am currently working on AMDGPU inline assembly and encountered problem with naming clobber registers in asm constraints. It looks like by default LLVM 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>;

...uld 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 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 &l...

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"

> On Dec 3, 2015, at 5:36 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Dec 3, 2015, at 5:11 PM, Smith, Kevin B <kevin.b.smith at intel.com <mailto:kevin.b.smith at intel.com>> wrote: >> >> >> >>> -----Original Message----- >>> From: Quentin Colombet [mailto:qcolombet at apple.com

Hi, In my target, certain intrinsic functions read or write the machine's flag registers. Some of my benchmarks rely on implicit data dependences among such intrinsics. How can I specify that these intrinsics carry this dependence, and that this dependence should be preserved through instruction selection? For example, suppose I have this snippet of IR: ; (i) Write to flags tail call

Make paravirt_types.h more understandable: - Use more consistent and logical naming - Simplify interfaces - Put related macros together - Improve whitespace Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> --- arch/x86/include/asm/paravirt_types.h | 104 ++++++++++++++++++---------------- 1 file changed, 54 insertions(+), 50 deletions(-) diff --git