search for: bndx

...components then you can use i128, or even <2 > x i64>. We have put some effort into trying to use i128 or v2i64, but it seems that post instruction selection LLVM is incredibly keen on putting values of those types in their 'correct' register class (e.g. XMM) in preference to the BNDx bounds registers. I haven't found any workaround for that, and adding an MVT code (where there is already precedent for oddballs like x86mmx and ppc_f128) seems to be low impact compared to any change to general register handling. As well, BNDx register contents do not really match the semanti...

...in On Sep 9, 2013, at 1:03 PM, Schoedel, Kevin P <kevin.p.schoedel at intel.com> wrote: > Hi all, > > I'm currently adding new instructions and registers to the X86 code > generator for Intel Memory Protection Extensions [1]. > > A class of special-purpose registers BNDx each holds 2 x 64-bit values. > The components are not individually readable or writable (except by > going through memory) but there are instructions that read only one > of the two elements. The two 64-bit values can be considered opaque, > that is, not useful outside of the specific...

Hi all, I'm currently adding new instructions and registers to the X86 code generator for Intel Memory Protection Extensions [1]. A class of special-purpose registers BNDx each holds 2 x 64-bit values. The components are not individually readable or writable (except by going through memory) but there are instructions that read only one of the two elements. The two 64-bit values can be considered opaque, that is, not useful outside of the specific instructions using t...

...real intention of the MPX developers since a fat pointer will break all ABIs, and MPX tries to preserve them. I don't think we need fat pointers to support MPX in LLVM -- it will complicate the implementation beyond necessity. (My 2c) All we need is to represent a 128-bit type that will live in BNDx registers. --kcc > > >> The pointer and metadata exist in separate registers, but single > instructions (loads and stores) operate on the pointer + metadata. > > Which MPX instructions do you mean here? > > Ah, sorry, I was confusing MPX with one of the other HardBoun...

...Fat pointers, however, are required for other architectures (including ours) and it would be nice to use the same general representation for all implementations of bounds-checked pointers (whether you call them fat pointers or not). > All we need is to represent a 128-bit type that will live in BNDx registers. Only if you want to push all of the work into the front end. David

...i128, or even <2 >> x i64>. > > We have put some effort into trying to use i128 or v2i64, but it > seems that post instruction selection LLVM is incredibly keen on > putting values of those types in their 'correct' register class > (e.g. XMM) in preference to the BNDx bounds registers. I haven't > found any workaround for that, and adding an MVT code (where there > is already precedent for oddballs like x86mmx and ppc_f128) seems > to be low impact compared to any change to general register > handling. > > As well, BNDx register contents d...

...Sep 2013, at 21:03, "Schoedel, Kevin P" <kevin.p.schoedel at intel.com> wrote: > Hi all, > > I'm currently adding new instructions and registers to the X86 code > generator for Intel Memory Protection Extensions [1]. > > A class of special-purpose registers BNDx each holds 2 x 64-bit values. > The components are not individually readable or writable (except by > going through memory) but there are instructions that read only one > of the two elements. The two 64-bit values can be considered opaque, > that is, not useful outside of the specific...

On 10 Sep 2013, at 10:28, Kostya Serebryany <kcc at google.com> wrote: > > > > On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com> wrote: > > > How did you come with 320 bits? > > 320=64*4+64, which is the size of the metadata table entry plus

On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com> wrote: > > > How did you come with 320 bits? > > 320=64*4+64, which is the size of the metadata table entry plus pointer > size, > > > Sorry, that should have been 192. The specification allows the

...Kevin P" <kevin.p.schoedel at intel.com> > wrote: > > > Hi all, > > > > I'm currently adding new instructions and registers to the X86 code > > generator for Intel Memory Protection Extensions [1]. > > > > A class of special-purpose registers BNDx each holds 2 x 64-bit values. > > The components are not individually readable or writable (except by > > going through memory) but there are instructions that read only one > > of the two elements. The two 64-bit values can be considered opaque, > > that is, not useful outs...