Skip to content
  1. May 05, 2013
    • Arnold Schwaighofer's avatar
      PatternMatch: Matcher for (un)ordered floating point min/max · e972d03f
      Arnold Schwaighofer authored 
      Add support for matching 'ordered' and 'unordered' floating point min/max
constructs.

In LLVM we can express min/max functions as a combination of compare and select.
We have support for matching such constructs for integers but not for floating
point. In floating point math there is no total order because of the presence of
'NaN'. Therefore, we have to be careful to preserve the original fcmp semantics
when interpreting floating point compare select combinations as a minimum or
maximum function. The resulting 'ordered/unordered' floating point maximum
function has to select the same value as the select/fcmp combination it is based
on.

 ordered_max(x,y)   = max(x,y) iff x and y are not NaN, y otherwise
 unordered_max(x,y) = max(x,y) iff x and y are not NaN, x otherwise
 ordered_min(x,y)   = min(x,y) iff x and y are not NaN, y otherwise
 unordered_min(x,y) = min(x,y) iff x and y are not NaN, x otherwise

This matches the behavior of the underlying select(fcmp(olt/ult/.., L, R), L, R)
construct.

Any code using this predicate has to preserve this semantics.

A follow-up patch will use this to implement floating point min/max reductions
in the vectorizer.

radar://13723044

llvm-svn: 181143
      e972d03f
  3. May 02, 2013
    • Filip Pizlo's avatar
      This exposes more MCJIT options via the C API: · 85e0d273
      Filip Pizlo authored 
      CodeModel: It's now possible to create an MCJIT instance with any CodeModel you like.  Previously it was only possible to 
create an MCJIT that used CodeModel::JITDefault.

EnableFastISel: It's now possible to turn on the fast instruction selector.

The CodeModel option required some trickery.  The problem is that previously, we were ensuring future binary compatibility in 
the MCJITCompilerOptions by mandating that the user bzero's the options struct and passes the sizeof() that he saw; the 
bindings then bzero the remaining bits.  This works great but assumes that the bitwise zero equivalent of any field is a 
sensible default value.

But this is not the case for LLVMCodeModel, or its internal equivalent, llvm::CodeModel::Model.  In both of those, the default 
for a JIT is CodeModel::JITDefault (or LLVMCodeModelJITDefault), which is not bitwise zero.

Hence this change introduces LLVMInitializeMCJITCompilerOptions(), which will initialize the user's options struct with
defaults. The user will use this in the same way that they would have previously used memset() or bzero(). MCJITCAPITest.cpp
illustrates the change, as does the comment in ExecutionEngine.h.

llvm-svn: 180893
      85e0d273
  5. May 01, 2013
  7. Apr 30, 2013
  9. Apr 29, 2013
    • Andrew Kaylor's avatar
      Exposing MCJIT through C API · 31be5eff
      Andrew Kaylor authored 
      Re-submitting with fix for OCaml dependency problems (removing dependency on SectionMemoryManager when it isn't used).

Patch by Fili Pizlo

llvm-svn: 180720
      31be5eff
  11. Apr 25, 2013
  13. Apr 24, 2013
    • Reid Kleckner's avatar
      Don't forward declare environ on Windows · 206ddd07
      Reid Kleckner authored 
      That seems to interact poorly with the environ and _environ macros
defined in MSVC's <stdlib.h>.

Also remove the incorrect comment about _NSGetEnviron().

llvm-svn: 180200
      206ddd07
  15. Apr 23, 2013
  17. Apr 22, 2013
  19. Apr 17, 2013
  21. Apr 12, 2013
  23. Apr 11, 2013
  25. Apr 10, 2013
  27. Apr 05, 2013
  29. Apr 04, 2013
  31. Mar 29, 2013
  33. Mar 28, 2013
  35. Mar 27, 2013
  37. Mar 16, 2013
  39. Mar 14, 2013
  41. Feb 28, 2013
  43. Feb 21, 2013
  45. Feb 20, 2013