similar to: [LLVMdev] [RFC] New function attributes for errno-setting functions

Hi Kevin, Thanks for working on this. We usually try really hard to avoid adding new types such as x86mmx. I don’t know the memory-protection instruction set at all but I imagine that you are not expecting other LLVM optimizations to interact with them right ? (it looks that way from this example[1]). If you are not accessing the individual components then you can use i128, or even <2 x

Maybe we can have two versions of the intrinsic function, "ordered" and "unordered", just like fcmp has [1]. Would that work ? [1] - http://llvm.org/docs/LangRef.html#fcmp-instruction On Dec 17, 2012, at 11:14 AM, "Schoedel, Kevin P" <kevin.p.schoedel at intel.com> wrote: > At Monday, December 17, 2012 2:05 PM, Nadav Rotem [mailto:nrotem at apple.com]

At Monday, December 17, 2012 2:05 PM, Nadav Rotem [mailto:nrotem at apple.com] wrote: >This part worries me. The new min/max intrinsics will only be useful if we could pattern match cmp/select into them. Yes, that's the obvious alternative. I don't think we have any strong opinion either way, and fcmp/select is certainly easier to implement. -- Kevin Schoedel, Software Developer,

Hi Kevin, We're also interested in support for fat pointers in LLVM/clang and it would be nice to have some general infrastructure for them (we currently have a load of hacks). There are a lot of research architectures with fat pointers, and MPX is likely to be just the first of many to start hitting real silicon soon. There are a few properties that we'd ideally want to represent in

On Wednesday, December 05, 2012 at 2:48 PM, Chris Lattner wrote: > > What does the community think? > > It seems inevitable. For the floating point version, please make it very clear > what the behavior of max(-0,+0) and related cases are. The following is our current proposal for llvm.fmax/fmin.*: [1] If exactly one argument is a NaN, the intrinsic returns the other argument.

On Tue, Sep 10, 2013 at 1:04 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > Hi Kevin, > > We're also interested in support for fat pointers in LLVM/clang and it > would be nice to have some general infrastructure for them (we currently > have a load of hacks). There are a lot of research architectures with fat > pointers, and MPX is likely to be just

Hi Kevin, Can you explain what kind of abstraction/support do you plan to implement over the MP instructions ? I imagine that you plan to add a few intrinsics, right ? I imagine that you don’t need the register allocator to allocate the BND registers or anything fancy like that. In that case the registers can be an immediate in the intrinsic. Maybe you can start by presenting the kind of

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

Hi, On Monday, September 09, 2013 4:20 PM, Nadav Rotem [mailto:nrotem at apple.com] wrote: > Thanks for working on this. We usually try really hard to avoid adding new > types such as x86mmx. I don't know the memory-protection instruction set at > all but I imagine that you are not expecting other LLVM optimizations to > interact with them right ? (it looks that way from this

This is about the target specification proposal described in http://nondot.org/sabre/LLVMNotes/TargetSpec.txt At the end of the year I spent a while on this, partly as a foot-wetting exercise for parts of LLVM I wouldn't otherwise look at. I did a partial implementation; enough to understand most of the issues (I hope) and get a clear idea of what would need to be done to phase it in. I

Nuno, Inspired by this email thread, I spent a bit of time today looking through the implementation of BoundsChecking::instrument(..). Based on my reading of prior work, it should be possible to do these checks in two comparisons, or possibly even one if the right assumptions could be made. Could you provide a bit of background of the expected domains of Size and Offset? In particular,

Hi Kevin, Thanks for your interest and for your deep analysis. Unfortunately, your approach doesn't catch all bugs and is vulnerable to an attack. Consider the following case: ...................... | ----- obj --- | | end ^ ptr ^ ^ end-of-memory The scenario is as follows: - an object is allocated in the last page of the address space - obj is byte

----- Original Message ----- > On 9/17/2013 2:43 PM, Hal Finkel wrote: > > > > That would depend on how this attribute was used; it could only be > > used by a pass that did actually understand what those side > > effects were (like the loop vectorizer understanding that, if > > errno is ignored, then vectorizing cos() is legal). I don't object > > to

I am investigating changing BoundsChecking to use address-based rather than size- & offset-based tests. To explain, here is a short code sample cribbed from one of the tests: %mem = tail call i8* @calloc(i64 1, i64 %elements) %memobj = bitcast i8* %mem to i64* %ptr = getelementptr inbounds i64* %memobj, i64 %index %4 = load i64* %ptr, align 8 Currently, the IR for bounds checking

On Dec 17, 2012, at 10:50 AM, "Schoedel, Kevin P" <kevin.p.schoedel at intel.com> wrote: > The intrinsics are not equivalent to an fcmp/select sequence. This part worries me. The new min/max intrinsics will only be useful if we could pattern match cmp/select into them. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 9/13/2013 3:37 PM, Hal Finkel wrote: > > No, I don't think so. If sqrt is not readnone or readonly, then it should potentially alias whatever the errno macro actually expands to (whether it is a global variable, and thread-local variable, a function call, or whatever). I'm not sure about this. How about this: extern int BLAH; #define errno BLAH Then we have int fd =

On Fri, Sep 13, 2013 at 2:07 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > > > Food for thought: If you have a codebase which can't use > > -fno-math-errno, because it relies on errno values from math > > functions, it may be a more effective long-term strategy to work on > > modernizing your codebase, eliminating the

On 9/17/2013 2:43 PM, Hal Finkel wrote: > > That would depend on how this attribute was used; it could only be used by a pass that did actually understand what those side effects were (like the loop vectorizer understanding that, if errno is ignored, then vectorizing cos() is legal). I don't object to making the name generic, but I want to make sure that we're all on the same page

On 9/12/2013 7:44 PM, Hal Finkel wrote: > > 1. 'writes-only-errno' > 2. 'errno-ignored' Do we really need the first one? We already know which standard functions could potentially set errno, and we know which standard functions don't modify any other storage (other than that which is passed via parameters). I think it's safe to assume that standard

On 9/12/2013 7:44 PM, Hal Finkel wrote: > > To fix this problem, I think that we need to stop treating errno as some arbitrary external state, and model is explicitly. In such case it would make sense to know when "errno" is read. This way we could detect whether it's actually used, whether or not the -fno-math-errno (or some generic -fno-xyz-errno) was specified. Problem