search for: schoedel

Displaying 20 results from an estimated 25 matches for "schoedel".

2012 Dec 17
3
[LLVMdev] max/min intrinsics
...ote: >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, Intel of Canada <kevin.p.schoedel at intel.com> +1 (519) 772-2580
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] wrote: >> This part worries me. The new min/max intrinsics will only be useful if we could pattern match cmp/select into them. > >...
2013 Sep 09
4
[LLVMdev] Intel Memory Protection Extensions (and types question)
...or other means of testing. http://llvm-reviews.chandlerc.com/D1630 Comments welcomed. [1] Chapter 9, Intel Architecture Instruction Set Extensions Programming Reference, July 2013, http://download-software.intel.com/sites/default/files/319433-015.pdf -- Kevin Schoedel, Software Developer, Intel of Canada <kevin.p.schoedel at intel.com> +1 (519) 772-2580
2012 Dec 17
2
[LLVMdev] max/min intrinsics
...alls to the C and OpenCL library functions. The intrinsics can be implemented as calls to the C or OpenCL library functions. They can also be implemented by IEEE 754 maxNum()/minNum() operations (but not vice versa). The intrinsics are not equivalent to an fcmp/select sequence. -- Kevin Schoedel, Software Developer, Intel of Canada <kevin.p.schoedel at intel.com> +1 (519) 772-2580 Disclaimer: the above just might possibly contain a statement that is not an official opinion of Intel.
2013 Sep 09
2
[LLVMdev] Intel Memory Protection Extensions (and types question)
...ne lightly, but adding an MVT code amounts to a handful of case labels. Over time we intend to write bounds checking instrumentation interoperable with that in gcc and icc; the plan is for this to be isolated to its own IR pass(es) so that there is no impact on compilation not using it. -- Kevin Schoedel, Software Developer, Intel of Canada <kevin.p.schoedel at intel.com> +1 (519) 772-2580
2013 Sep 09
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
...u are not accessing the individual components then you can use i128, or even <2 x i64>. Thanks, Nadav [1] http://software.intel.com/en-us/blogs/2013/07/22/intel-memory-protection-extensions-intel-mpx-support-in-the-gnu-toolchain 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. > T...
2012 Nov 26
2
[LLVMdev] RFC: change BoundsChecking.cpp to use address-based tests
...rocessors (and ptrtoint typically free). I have prototyped address-based testing (with one wart that makes it not production grade) but not done benchmarking and analysis. Before I do that, I'm looking for any reasons that this method of bounds checking would be a "no go". -- Kevin Schoedel kevin.p.schoedel at intel.com +1-519-772-2580 SSG-DPD-ECDL-DMP - Intel Dynamic Mobility and Parallelism
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
...e 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 intrinsics that you want to implement. Thanks, Nadav On Sep 9, 2013, at 2:00 PM, Schoedel, Kevin P <kevin.p.schoedel at intel.com> wrote: > 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...
2012 Nov 26
0
[LLVMdev] RFC: change BoundsChecking.cpp to use address-based tests
...since we can take advantage of the overflow flag that is set by the 'sub' instruction. Last time I checked (in July), LLVM was not performing this optimization, but it may have been fixed in the meantime. There are still 3 jumps, though. Nuno ----- Original Message ----- From: "Schoedel, Kevin P" <kevin.p.schoedel at intel.com> To: <llvmdev at cs.uiuc.edu> Sent: Monday, November 26, 2012 3:56 PM Subject: [LLVMdev] RFC: change BoundsChecking.cpp to use address-based tests >I am investigating changing BoundsChecking to use address-based rather > than size- &...
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
...enough for that. We also need explicit support for inttoptr and ptrtoint in the back end, as moving between integer and address registers requires explicit conversion for us, and somewhat better matching for pointers in different address spaces in TableGen. David On 9 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....
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 --------------...
2012 Dec 04
2
[LLVMdev] RFC: change BoundsChecking.cpp to use address-based tests
...e overflow flag that is set by the > 'sub' instruction. Last time I checked (in July), LLVM was not > performing this optimization, but it may have been fixed in the > meantime. There are still 3 jumps, though. > > Nuno > > > ----- Original Message ----- From: "Schoedel, Kevin P" > <kevin.p.schoedel at intel.com> > To: <llvmdev at cs.uiuc.edu> > Sent: Monday, November 26, 2012 3:56 PM > Subject: [LLVMdev] RFC: change BoundsChecking.cpp to use address-based > tests > > >> I am investigating changing BoundsChecking to use...
2014 Jun 12
1
memory leak with vlan tagged traffic in switch mode
...from the ethernet header, when I transport 8021q tagged traffic. If I change my config from switch to hub mode, everything works fine. Are there any drawbacks If I use hub mode when there are only two connected sites? Thanks for your help Florian -----Original Message----- From: "Florian Schoedel" <Florian.Schoedel at meteringservice.de> To: tinc-devel at tinc-vpn.org Date: Wed, 11 Jun 2014 19:40:45 +0200 Subject: Fwd: memory leak Hi, I've observed this strange behaviour for a while in my test environment. It looks like that all problems gone away when I switch to "hu...
2013 Feb 13
2
[LLVMdev] TargetSpec
...ld continue to do that. We can > even extend it to reason about OS's etc. The problem here is that tblgen depends on Support. I'm looking for guidance on the right thing to do here, and (depending on the answer) possibly some suggestions on getting the build systems to do it. -- Kevin Schoedel kevin.p.schoedel at intel.com +1-519-772-2580 SSG-DPD-ECDL-DMP - Intel Dynamic Mobility and Parallelism
2013 Sep 10
2
[LLVMdev] Intel Memory Protection Extensions (and types question)
...explicit support for inttoptr and ptrtoint in the back end, > as moving between integer and address registers requires explicit > conversion for us, and somewhat better matching for pointers in different > address spaces in TableGen. > > David > > On 9 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 register...
2013 Sep 19
0
[LLVMdev] [RFC] New function attributes for errno-setting functions
...zing the definition (or declaration, pre-'11) of errno? The language standards impose strict conditions it must meet: - be defined (declared) within <errno.h> or <cerrno>; - in C11 and C++11, be a macro; - pre-'11, alternatively be an identifier with external linkage. -- Kevin Schoedel, Software Developer, Intel of Canada <kevin.p.schoedel at intel.com> +1 (519) 772-2580
2012 Dec 04
0
[LLVMdev] RFC: change BoundsChecking.cpp to use address-based tests
Hi, > Could you provide a bit of background of the expected domains of Size and > Offset? In particular, are they signed or unsigned integers? A > non-negative size doesn't seem to make much sense in this context, but > depending on how it's calculated I could see it arising. Is a zero Size > something that might arise here? I'm assuming the Offset comes from an
2014 Jun 11
0
Fwd: memory leak
...t tunnel? In my environment the side, which is receiving arp requests from the wired interface, is running out of memory. The other side, which receivces the arp requests through the tunnel doesn't run out of memory. Best regards Florian -----Original Message----- From: "Florian Schoedel" <Florian.Schoedel at meteringservice.de> To: tinc-devel at tinc-vpn.org Date: Fri, 06 Jun 2014 09:50:33 +0200 Subject: memory leak Hi, I am running tinc on alpine linux 2.7.8 in 2 seperate environments. The first environment is running for about a month without any problems. The sec...
2012 Dec 05
0
[LLVMdev] max/min intrinsics
On Dec 5, 2012, at 8:26 AM, "Redmond, Paul" <paul.redmond at intel.com> wrote: > I have been working on a patch to add support for max/min reductions in LoopVectorize. One of the comments that came up in review is that the implementation could be simplified (and less fragile) if max and min intrinsics were recognized rather than looking for compare-select sequences. >
2013 Sep 10
0
[LLVMdev] Intel Memory Protection Extensions (and types question)
On 10 Sep 2013, at 12:13, Kostya Serebryany <kcc at google.com> wrote: > Well, ok, you can treat this as a 192-bit fat pointer, but AFAICT this is not the real intention of the MPX developers > since a fat pointer will break all ABIs, and MPX tries to preserve them. MPX is an implementation of the HardBound concept from UPenn, where this was a design goal (see also their 'low-fat