search for: wangmp

....barrier(i1 true,i1 true,i1 true,i1 true,i1 true)". Is that right? I would like a little finer control to express just a write barrier (st-st) or a read barrier. -- Mon Ping On Sep 17, 2008, at 5:50 AM, Andrew Lenharth wrote: > On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang <wangmp at apple.com> > wrote: >> >> I would like access to LLVM memory barrier instruction as a built-in >> from clang, which means that I need a name for it. In gcc, I see >> names >> like __builtin_ia32_mfence but those refers to X86 SSE instruction >> that...

On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang <wangmp at apple.com> wrote: > > I would like access to LLVM memory barrier instruction as a built-in > from clang, which means that I need a name for it. In gcc, I see names > like __builtin_ia32_mfence but those refers to X86 SSE instruction > that we support. I don't see a gcc nam...

I would like access to LLVM memory barrier instruction as a built-in from clang, which means that I need a name for it. In gcc, I see names like __builtin_ia32_mfence but those refers to X86 SSE instruction that we support. I don't see a gcc name that has the same semantics as our barrier instruction. For a name, I was thinking of __builtin_memory_barrier or

...e overloaded in the same way that LLVM's builtin is for use in clang, with the default version being the full memory barrier. Luke > > -- Mon Ping > > > On Sep 17, 2008, at 5:50 AM, Andrew Lenharth wrote: > >> On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang <wangmp at apple.com> >> wrote: >>> I would like access to LLVM memory barrier instruction as a built-in >>> from clang, which means that I need a name for it. In gcc, I see >>> names >>> like __builtin_ia32_mfence but those refers to X86 SSE instruction &gt...

...#39;s builtin is for use in clang, with the default > version being the full memory barrier. > > Luke > >> >> -- Mon Ping >> >> >> On Sep 17, 2008, at 5:50 AM, Andrew Lenharth wrote: >> >>> On Tue, Sep 16, 2008 at 5:42 PM, Mon Ping Wang <wangmp at apple.com> >>> wrote: >>>> I would like access to LLVM memory barrier instruction as a built- >>>> in >>>> from clang, which means that I need a name for it. In gcc, I see >>>> names >>>> like __builtin_ia32_mfence but thos...

On Mon, Sep 29, 2008 at 8:11 PM, Mon Ping Wang <wangmp at apple.com> wrote: > The problem with generating insert and extracts is that we can generate poor > code > %tmp16 = extractelement <4 x float> %f4b, i32 0 > %f8a = insertelement <8 x float> %f8a, float %tmp16, i32 0 > %tmp18 = extractelement <...

Hi, The current definition of shuffle vector is <result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <n x i32> <mask> ; yields <n x <ty>> The first two operands of a 'shufflevector' instruction are vectors with types that match each other and types that match the result of the instruction. The third

Hello All, I just svn update % svn info . Path: . URL: http://llvm.org/svn/llvm-project/llvm/trunk Repository Root: http://llvm.org/svn/llvm-project Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8 Revision: 54012 Node Kind: directory Schedule: normal Last Changed Author: wangmp Last Changed Rev: 54007 Last Changed Date: 2008-07-25 03:30:26 +0200 (Fri, 25 Jul 2008) make[3]: Entering directory `/usr/src/Lang/llvm/lib/Analysis/IPA' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/src/Lang/llvm/lib/Analysis/IPA' make[2]: Leaving directory...

...a program that has a reducible graph (any C code without goto/setjmp) and generate one that is irreducible? If it is the case that the code is actually structured coming in, a simple pattern matcher could turn everything into if/endif and so on. Ben On 14/08/2008 18:39, "Mon P Wang" <wangmp at apple.com> wrote: > Hi Ben, > > > On Aug 12, 2008, at 11:36 AM, Benedict Gaster wrote: > >> Hi Owen, >> >> On 12/08/2008 16:52, "Owen Anderson" <resistor at mac.com> wrote: >> >> >>> >>> SNIP >>...

Hi Ben, On Aug 12, 2008, at 11:36 AM, Benedict Gaster wrote: > Hi Owen, > > On 12/08/2008 16:52, "Owen Anderson" <resistor at mac.com> wrote: > >> >> SNIP >> >> >> I'm still not seeing how these two are any different. You just >> replace the text of "if" with "br", and add the explicit target >>

Hi Owen, On 12/08/2008 16:52, "Owen Anderson" <resistor at mac.com> wrote: > > SNIP > > > I'm still not seeing how these two are any different. You just replace the > text of "if" with "br", and add the explicit target labels. I should also > point out that, in LLVM IR, the order the blocks are laid out in is not > meaningful

Just noticed that when we generate a custom lowering for some atomics that we forgot to transfer the MemOperand to the new instruction that touches memory. -- Mon Ping Index: lib/Target/X86/X86ISelLowering.cpp =================================================================== --- lib/Target/X86/X86ISelLowering.cpp (revision 53702) +++ lib/Target/X86/X86ISelLowering.cpp (working copy) @@

Hi, I have a problem with creating a MFENCE on X86 with SSE In X86InstrSSE.td, a MFENCE is def MFENCE : I<0xAE, MRM6m, (outs), (ins), "mfence", [(int_x86_sse2_mfence)]>, TB, Requires< [HasSSE2]>; In X86CodeEmitter.cpp in emitInstruction case X86II::MRM6m: case X86II::MRM7m: { intptr_t PCAdj = (CurOp+4 != NumOps) ?

To my knowledge, I don't think there is an easy way to get the MVT information from a MachineOperand. Why do you need it for? In my mind, the MachineInstr and its associated operands represent a physical machine instruction and I typically want to think of those as machine opcodes and machine register files. I am typically interested in the mapping of MVTs to register classes

Hi, I agree that the more general shufflevector is more useful. I narrowed the original proposal a little bit because of the concern for the implementation cost. However, the slightly narrowed definition will probably require falling backing to generate insert and extracts for complex masks so it is possible that there will be no extra cost in supporting the more general definition.

Hi, Sorry for breakage, I'll look into this right now. I guess llvm-gcc doesn't use llvm tablegen results to help create intrinsic names. -- Mon Ping On Jul 30, 2008, at 1:51 PM, Duncan Sands wrote: > Hi, I see this when building llvm-gcc on x86-32 linux: > > xgcc -Bgcc/ -B/usr/local/gnat-llvm/i686-pc-linux-gnu/bin/ -B/usr/ > local/gnat-llvm/i686-pc-linux-gnu/lib/

Hi, When setting -mattr option on X86, I would like to treat MMX separately from SSE levels. This would allow a client who sets the attributes directly to set the SSE level independent of MMX, e.g., llc -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If anyone objects to this change, please let me

The address qualifier is stored in the type of %result. From that operand, you can get the Value and then call getType. The type for result should be a PointerType which you cast to a PointerType and get the getAddressSpace e.g. cast<PointerType>(Ty)->getAddressSpace() -- Mon Ping On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: > How do I access the address qualifier

Hi, I should double check this but I viewed the "." as being useful to separate different parameter types in case we need to overload on multiple parameters. I think of p0i32 as the type of a single parameter. If we had multiple parameters with complex types, I think it might become harder to read if we separated each component, .e.g., a hypothetical intrinsic that takes a

Hi, Though I haven't looked into the implementation details, at the high level, I personally think having the address space argument is cleaner than having it encoded as a pointer. The memory barrier places a barrier on the entire address space. When I see the %ptr11 on the memory barrier instruction, my first instinct is to that it is a memory barrier on the region of memory that