| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 149237
|
|
|
|
|
|
| |
are now in IntrinsicsX86.td.
llvm-svn: 149235
|
|
|
|
|
|
| |
connecting intrinsics and builtins in IntrinsicsX86.td.
llvm-svn: 149233
|
|
|
|
|
|
|
|
|
| |
There is really no reason to have these only available on x86. It's
just __builtin_c[tl]z for shorts.
Modernize the test while at it.
llvm-svn: 149183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARM supports clz and ctz directly and both operations have well-defined
results for zero. There is no disadvantage in performance to using the
defined-at-zero versions of llvm.ctlz/cttz intrinsics. We're running into
ARM-specific code written with the assumption that __builtin_clz(0) == 32,
even though that value is technically undefined. The code is failing now
because of llvm optimizations that are taking advantage of the undef
behavior (specifically svn r147255). There's nothing wrong with that
optimization on x86 where any incorrect assumptions about __builtin_clz(0)
will quickly be exposed. For ARM, though, optimizations based on that undef
behavior are likely to cause subtle bugs. Other targets with defined-at-zero
clz/ctz support may want to override the default behavior as well.
llvm-svn: 149086
|
|
|
|
|
|
|
|
|
|
| |
"use the new ConstantVector::getSplat method where it makes sense."
Also simplify a bunch of code to use the Builder->getInt32 instead
of doing it the hard and ugly way. Much more progress could be made
here, but I don't plan to do it.
llvm-svn: 148926
|
|
|
|
|
|
|
| |
Original log:
use the new ConstantVector::getSplat method where it makes sense.
llvm-svn: 148907
|
|
|
|
| |
llvm-svn: 148902
|
|
|
|
| |
llvm-svn: 148577
|
|
|
|
|
|
| |
__builtin_*abs. Patch by Ruben Van Boxem.
llvm-svn: 148340
|
|
|
|
|
|
| |
This allows -Wswitch-enum to find switches that need updating when these enums are modified.
llvm-svn: 148281
|
|
|
|
| |
llvm-svn: 147677
|
|
|
|
|
|
|
|
| |
builtins.
This fixes PR11711.
llvm-svn: 147655
|
|
|
|
|
|
| |
clients. No functionality change.
llvm-svn: 147318
|
|
|
|
| |
llvm-svn: 147263
|
|
|
|
| |
llvm-svn: 146857
|
|
|
|
| |
llvm-svn: 146413
|
|
|
|
|
|
|
|
|
| |
setting the is_zero_undef flag appropriately to true as that matches the
semantics of these GCC builtins.
This is the Clang side of r146357 in LLVM.
llvm-svn: 146358
|
|
|
|
| |
llvm-svn: 144065
|
|
|
|
|
|
|
|
|
| |
This patch just adds a simple NeonTypeFlags class to replace the various
hardcoded constants that had been used until now. Unfortunately I couldn't
figure out a good way to avoid duplicating that class between clang and
TableGen, but since it's small and rarely changes, that's not so bad.
llvm-svn: 144054
|
|
|
|
|
|
|
|
| |
implicitly perform an lvalue-to-rvalue conversion if used on an lvalue
expression. Also improve the documentation of Expr::Evaluate* to indicate which
of them will accept expressions with side-effects.
llvm-svn: 143263
|
|
|
|
| |
llvm-svn: 141632
|
|
|
|
|
|
|
|
|
|
|
| |
- Remodel Expr::EvaluateAsInt to behave like the other EvaluateAs* functions,
and add Expr::EvaluateKnownConstInt to capture the current fold-or-assert
behaviour.
- Factor out evaluation of bitfield bit widths.
- Fix a few places which would evaluate an expression twice: once to determine
whether it is a constant expression, then again to get the value.
llvm-svn: 141561
|
|
|
|
|
|
|
|
| |
__builtin_llvm_memory_barrier.
__atomic_thread_fence will be landing soon as a replacement, wrapping around the new fence instruction.
llvm-svn: 141332
|
|
|
|
| |
llvm-svn: 140637
|
|
|
|
| |
llvm-svn: 140367
|
|
|
|
| |
llvm-svn: 139678
|
|
|
|
|
|
|
| |
the builtin is really just a predefined declaration. These are
totally valid to cast.
llvm-svn: 139657
|
|
|
|
|
|
| |
Make clang use Acquire loads and Release stores where necessary.
llvm-svn: 139650
|
|
|
|
| |
llvm-svn: 139648
|
|
|
|
| |
llvm-svn: 139643
|
|
|
|
| |
llvm-svn: 139424
|
|
|
|
|
|
|
| |
annotate global, local variables, struct fields, or arbitrary statements (using
the __builtin_annotation), rdar://8037476.
llvm-svn: 139423
|
|
|
|
|
|
|
|
|
|
| |
(which will go away). LLVM CodeGen does almost exactly the same thing with these and the old intrinsics, so I'm reasonably confident this will not break anything.
There are still a few issues which need to be resolved with code generation for atomic load and store, so I'm not converting the places which need those for now.
I'm not entirely sure what to do about __builtin_llvm_memory_barrier: the fence instruction doesn't expose all the possibilities which can be expressed by __builtin_llvm_memory_barrier. I would appreciate hearing from anyone who is using this intrinsic.
llvm-svn: 139216
|
|
|
|
|
|
| |
bunch of others I haven't touched.
llvm-svn: 137867
|
|
|
|
|
|
|
|
|
| |
Unlike most of the other Neon intrinsics, these are not overloaded and do not
have the extra argument that specifies the vector type. This has not been
fatal because the lane number operand is supposed to be an ICE and so that
value has harmlessly been used as the type identifier. Radar 9901281.
llvm-svn: 137550
|
|
|
|
| |
llvm-svn: 136461
|
|
|
|
| |
llvm-svn: 135910
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
|
|
| |
previously explicit non-default constructors were used.
Mostly mechanical with some manual reformatting.
llvm-svn: 135390
|
|
|
|
| |
llvm-svn: 135370
|
|
|
|
| |
llvm-svn: 135265
|
|
|
|
|
|
| |
function in LLVM does.
llvm-svn: 135155
|
|
|
|
| |
llvm-svn: 134831
|
|
|
|
| |
llvm-svn: 134761
|
|
|
|
| |
llvm-svn: 134743
|
|
|
|
|
|
|
|
| |
Sorry, this was a bad idea. Within clang these builtins are in a separate
"ARM" namespace, but the actual builtin names should clearly distinguish tha
they are target specific.
llvm-svn: 133833
|
|
|
|
| |
llvm-svn: 133826
|
|
|
|
| |
llvm-svn: 133365
|
|
|
|
|
|
| |
whether it's a data or instruction cache access.
llvm-svn: 132977
|