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

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] [RFC] New function attributes for errno-setting functions"

2013 Sep 09
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
2012 Dec 17
0
[LLVMdev] max/min intrinsics
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]
2012 Dec 17
3
[LLVMdev] max/min intrinsics
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,
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
2012 Dec 17
2
[LLVMdev] max/min intrinsics
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.
2013 Sep 10
2
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
2013 Sep 09
4
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
2013 Sep 09
2
[LLVMdev] Intel Memory Protection Extensions (and types question)
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
2013 Feb 13
2
[LLVMdev] TargetSpec
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
2012 Dec 04
2
[LLVMdev] RFC: change BoundsChecking.cpp to use address-based tests
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,
2012 Nov 26
0
[LLVMdev] RFC: change BoundsChecking.cpp to use address-based tests
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
2013 Sep 17
1
[LLVMdev] [RFC] New function attributes for errno-setting functions
----- 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
2012 Nov 26
2
[LLVMdev] RFC: change BoundsChecking.cpp to use address-based tests
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
2012 Dec 17
0
[LLVMdev] max/min intrinsics
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:
2013 Sep 13
0
[LLVMdev] [RFC] New function attributes for errno-setting functions
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 =
2013 Sep 13
0
[LLVMdev] [RFC] New function attributes for errno-setting functions
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
2013 Sep 17
0
[LLVMdev] [RFC] New function attributes for errno-setting functions
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
2013 Sep 17
0
[LLVMdev] [RFC] New function attributes for errno-setting functions
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
2013 Sep 13
0
[LLVMdev] [RFC] New function attributes for errno-setting functions
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