summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExprScalar.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [ubsan] Detect invalid unsigned pointer index expression (clang)Vedant Kumar2017-06-121-20/+31
| | | | | | | | | | | | | | | | | | | | | | | | Adding an unsigned offset to a base pointer has undefined behavior if the result of the expression would precede the base. An example from @regehr: int foo(char *p, unsigned offset) { return p + offset >= p; // This may be optimized to '1'. } foo(p, -1); // UB. This patch extends the pointer overflow check in ubsan to detect invalid unsigned pointer index expressions. It changes the instrumentation to only permit non-negative offsets in pointer index expressions when all of the GEP indices are unsigned. Testing: check-llvm, check-clang run on a stage2, ubsan-instrumented build. Differential Revision: https://reviews.llvm.org/D33910 llvm-svn: 305216
* [CodeGen] Surround assertion with parentheses.Davide Italiano2017-06-011-1/+1
| | | | | | This should placate GCC's -Wparentheses. llvm-svn: 304499
* [ubsan] Add a check for pointer overflow UBVedant Kumar2017-06-011-34/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check pointer arithmetic for overflow. For some more background on this check, see: https://wdtz.org/catching-pointer-overflow-bugs.html https://reviews.llvm.org/D20322 Patch by Will Dietz and John Regehr! This version of the patch is different from the original in a few ways: - It introduces the EmitCheckedInBoundsGEP utility which inserts checks when the pointer overflow check is enabled. - It does some constant-folding to reduce instrumentation overhead. - It does not check some GEPs in CGExprCXX. I'm not sure that inserting checks here, or in CGClass, would catch many bugs. Possible future directions for this check: - Introduce CGF.EmitCheckedStructGEP, to detect overflows when accessing structures. Testing: Apart from the added lit test, I ran check-llvm and check-clang with a stage2, ubsan-instrumented clang. Will and John have also done extensive testing on numerous open source projects. Differential Revision: https://reviews.llvm.org/D33305 llvm-svn: 304459
* CodeGen: Cast alloca to expected address spaceYaxun Liu2017-05-181-4/+3
| | | | | | | | | | | Alloca always returns a pointer in alloca address space, which may be different from the type defined by the language. For example, in C++ the auto variables are in the default address space. Therefore cast alloca to the expected address space when necessary. Differential Revision: https://reviews.llvm.org/D32248 llvm-svn: 303370
* [ubsan] Mark overflow checks with !nosanitizeVedant Kumar2017-05-091-1/+1
| | | | | | | | | Sanitizer instrumentation generally needs to be marked with !nosanitize, but we're not doing this properly for ubsan's overflow checks. r213291 has more information about why this is needed. llvm-svn: 302598
* Rename a method. NFC.Vedant Kumar2017-05-091-3/+3
| | | | llvm-svn: 302490
* [ubsan] Skip overflow checks on safe arithmetic (fixes PR32874)Vedant Kumar2017-05-021-8/+78
| | | | | | | | | | | | | | | | | | | | | | | | Currently, ubsan emits overflow checks for arithmetic that is known to be safe at compile-time, e.g: 1 + 1 => CheckedAdd(1, 1) This leads to breakage when using the __builtin_prefetch intrinsic. LLVM expects the arguments to @llvm.prefetch to be constant integers, and when ubsan inserts unnecessary checks on the operands to the intrinsic, this contract is broken, leading to verifier failures (see PR32874). Instead of special-casing __builtin_prefetch for ubsan, this patch fixes the underlying problem, i.e that clang currently emits unnecessary overflow checks. Testing: I ran the check-clang and check-ubsan targets with a stage2, ubsan-enabled build of clang. I added a regression test for PR32874, and some extra checking to make sure we don't regress runtime checking for unsafe arithmetic. The existing ubsan-promoted-arithmetic.cpp test also provides coverage for this change. llvm-svn: 301988
* Set FMF for -ffp-contract=fastAdam Nemet2017-04-041-4/+24
| | | | | | | | | | | | | | With this, FMF(contract) becomes an alternative way to express the request to contract. These are currently only propagated for FMul, FAdd and FSub. The rest will be added as more FMFs are hooked up for this. This is toward fixing PR25721. Differential Revision: https://reviews.llvm.org/D31168 llvm-svn: 299469
* Preserve vec3 type.Jin-Gu Kang2017-04-041-5/+12
| | | | | | | | | | | | | | Summary: Preserve vec3 type with CodeGen option. Reviewers: Anastasia, bruno Reviewed By: Anastasia Subscribers: bruno, ahatanak, cfe-commits Differential Revision: https://reviews.llvm.org/D30810 llvm-svn: 299445
* Use FPContractModeKind universallyAdam Nemet2017-03-291-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FPContractModeKind is the codegen option flag which is already ternary (off, on, fast). This makes it universally the type for the contractable info across the front-end: * In FPOptions (i.e. in the Sema + in the expression nodes). * In LangOpts::DefaultFPContractMode which is the option that initializes FPOptions in the Sema. Another way to look at this change is that before fp-contractable on/off were the only states handled to the front-end: * For "on", FMA folding was performed by the front-end * For "fast", we simply forwarded the flag to TargetOptions to handle it in LLVM Now off/on/fast are all exposed because for fast we will generate fast-math-flags during CodeGen. This is toward moving fp-contraction=fast from an LLVM TargetOption to a FastMathFlag in order to fix PR25721. --- This is a recommit of r299027 with an adjustment to the test CodeGenCUDA/fp-contract.cu. The test assumed that even though -ffp-contract=on is passed FE-based folding of FMA won't happen. This is obviously wrong since the user is asking for this explicitly with the option. CUDA is different that -ffp-contract=fast is on by default. The test used to "work" because contract=fast and contract=on were maintained separately and we didn't fold in the FE because contract=fast was on due to the target-default. This patch consolidates the contract=on/fast/off state into a ternary state hence the change in behavior. --- Differential Revision: https://reviews.llvm.org/D31167 llvm-svn: 299033
* Revert "Use FPContractModeKind universally"Adam Nemet2017-03-291-1/+6
| | | | | | | | This reverts commit r299027. It's causing a test failure in clang's CodeGenCUDE/fp-contract.cu llvm-svn: 299029
* Use FPContractModeKind universallyAdam Nemet2017-03-291-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | FPContractModeKind is the codegen option flag which is already ternary (off, on, fast). This makes it universally the type for the contractable info across the front-end: * In FPOptions (i.e. in the Sema + in the expression nodes). * In LangOpts::DefaultFPContractMode which is the option that initializes FPOptions in the Sema. Another way to look at this change is that before fp-contractable on/off were the only states handled to the front-end: * For "on", FMA folding was performed by the front-end * For "fast", we simply forwarded the flag to TargetOptions to handle it in LLVM Now off/on/fast are all exposed because for fast we will generate fast-math-flags during CodeGen. This is toward moving fp-contraction=fast from an LLVM TargetOption to a FastMathFlag in order to fix PR25721. Differential Revision: https://reviews.llvm.org/D31167 llvm-svn: 299027
* Encapsulate FPOptions and use it consistentlyAdam Nemet2017-03-271-6/+6
| | | | | | | | | | | | | | | | | | Sema holds the current FPOptions which is adjusted by 'pragma STDC FP_CONTRACT'. This then gets propagated into expression nodes as they are built. This encapsulates FPOptions so that this propagation happens opaquely rather than directly with the fp_contractable on/off bit. This allows controlled transitioning of fp_contractable to a ternary value (off, on, fast). It will also allow adding more fast-math flags later. This is toward moving fp-contraction=fast from an LLVM TargetOption to a FastMathFlag in order to fix PR25721. Differential Revision: https://reviews.llvm.org/D31166 llvm-svn: 298877
* [coroutines] Add codegen for await and yield expressionsGor Nishanov2017-03-261-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Details: Emit suspend expression which roughly looks like: auto && x = CommonExpr(); if (!x.await_ready()) { llvm_coro_save(); x.await_suspend(...); (*) llvm_coro_suspend(); (**) } x.await_resume(); where the result of the entire expression is the result of x.await_resume() (*) If x.await_suspend return type is bool, it allows to veto a suspend: if (x.await_suspend(...)) llvm_coro_suspend(); (**) llvm_coro_suspend() encodes three possible continuations as a switch instruction: %where-to = call i8 @llvm.coro.suspend(...) switch i8 %where-to, label %coro.ret [ ; jump to epilogue to suspend i8 0, label %yield.ready ; go here when resumed i8 1, label %yield.cleanup ; go here when destroyed ] llvm-svn: 298784
* [ubsan] Add a nullability sanitizerVedant Kumar2017-03-141-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach UBSan to detect when a value with the _Nonnull type annotation assumes a null value. Call expressions, initializers, assignments, and return statements are all checked. Because _Nonnull does not affect IRGen, the new checks are disabled by default. The new driver flags are: -fsanitize=nullability-arg (_Nonnull violation in call) -fsanitize=nullability-assign (_Nonnull violation in assignment) -fsanitize=nullability-return (_Nonnull violation in return stmt) -fsanitize=nullability (all of the above) This patch builds on top of UBSan's existing support for detecting violations of the nonnull attributes ('nonnull' and 'returns_nonnull'), and relies on the compiler-rt support for those checks. Eventually we will need to update the diagnostic messages in compiler-rt (there are FIXME's for this, which will be addressed in a follow-up). One point of note is that the nullability-return check is only allowed to kick in if all arguments to the function satisfy their nullability preconditions. This makes it necessary to emit some null checks in the function body itself. Testing: check-clang and check-ubsan. I also built some Apple ObjC frameworks with an asserts-enabled compiler, and verified that we get valid reports. Differential Revision: https://reviews.llvm.org/D30762 llvm-svn: 297700
* Don't assume cleanup emission preserves dominance in expr evaluationReid Kleckner2017-03-061-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
* Fix -Wparentheses warningVedant Kumar2017-02-251-2/+2
| | | | llvm-svn: 296246
* Retry: [profiling] Fix profile counter increment when emitting selects (PR32019)Vedant Kumar2017-02-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 2nd attempt: the first was in r296231, but it had a use after lifetime bug. Clang has logic to lower certain conditional expressions directly into llvm select instructions. However, it does not emit the correct profile counter increment as it does this: it emits an unconditional increment of the counter for the 'then branch', even if the value selected is from the 'else branch' (this is PR32019). That means, given the following snippet, we would report that "0" is selected twice, and that "1" is never selected: int f1(int x) { return x ? 0 : 1; ^2 ^0 } f1(0); f1(1); Fix the problem by using the instrprof_increment_step intrinsic to do the proper increment. llvm-svn: 296245
* Revert "[profiling] Fix profile counter increment when emitting selects ↵Vedant Kumar2017-02-251-4/+2
| | | | | | | | | | | | | | | | | | | | | (PR32019)" This reverts commit r296231. It causes an assertion failure on 32-bit machines clang: /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/lib/IR/Instructions.cpp:263: void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"' failed. llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5fbfa) llvm::sys::RunSignalHandlers() (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dc7e) SignalHandler(int) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dde2) __restore_rt (/lib64/libpthread.so.0+0x3f1d00efa0) __GI_raise /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 __GI_abort /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/stdlib/abort.c:92:0 __assert_fail_base /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/assert/assert.c:92:0 (/lib64/libc.so.6+0x3f1c82e622) llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, llvm::Twine const&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1804e3a) clang::CodeGen::CodeGenPGO::emitCounterIncrement(clang::CodeGen::CGBuilderTy&, clang::Stmt const*, llvm::Value*) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1ec7891) llvm-svn: 296234
* [profiling] Fix profile counter increment when emitting selects (PR32019)Vedant Kumar2017-02-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Clang has logic to lower certain conditional expressions directly into llvm select instructions. However, it does not emit the correct profile counter increment as it does this: it emits an unconditional increment of the counter for the 'then branch', even if the value selected is from the 'else branch' (this is PR32019). That means, given the following snippet, we would report that "0" is selected twice, and that "1" is never selected: int f1(int x) { return x ? 0 : 1; ^2 ^0 } f1(0); f1(1); Fix the problem by using the instrprof_increment_step intrinsic to do the proper increment. llvm-svn: 296231
* [ubsan] Detect signed overflow UB in remainder operationsVedant Kumar2017-02-251-4/+4
| | | | | | | | | Teach ubsan to diagnose remainder operations which have undefined behavior due to signed overflow (e.g INT_MIN % -1). Differential Revision: https://reviews.llvm.org/D29437 llvm-svn: 296214
* [ubsan] Omit superflous overflow checks for promoted arithmetic (PR20193)Vedant Kumar2017-02-251-4/+71
| | | | | | | | | | | | | | | | C requires the operands of arithmetic expressions to be promoted if their types are smaller than an int. Ubsan emits overflow checks when this sort of type promotion occurs, even if there is no way to actually get an overflow with the promoted type. This patch teaches clang how to omit the superflous overflow checks (addressing PR20193). Testing: check-clang and check-ubsan. Differential Revision: https://reviews.llvm.org/D29369 llvm-svn: 296213
* [ObjC][CodeGen] CodeGen support for @available.Erik Pilkington2017-02-231-0/+18
| | | | | | | | | | | | CodeGens uses of @available into calls to the compiler-rt function __isOSVersionAtLeast. This commit is part of a feature that I proposed here: http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html Differential revision: https://reviews.llvm.org/D27827 llvm-svn: 296015
* Re-apply "[ubsan] Sanity-check shift amounts before truncation"Vedant Kumar2017-01-301-7/+9
| | | | | | | | | | | | | | | | | | | This re-applies r293343 (reverts commit r293475) with a fix for an assertion failure caused by a missing integer cast. I tested this patch by using the built compiler to compile X86FastISel.cpp.o with ubsan. Original commit message: Ubsan does not report UB shifts in some cases where the shift exponent needs to be truncated to match the type of the shift base. We perform a range check on the truncated shift amount, leading to false negatives. Fix the issue (PR27271) by performing the range check on the original shift amount. Differential Revision: https://reviews.llvm.org/D29234 llvm-svn: 293572
* Revert "r293343 - [ubsan] Sanity-check shift amounts before truncationAlex Lorenz2017-01-301-2/+2
| | | | | | | | | | | (fixes PR27271)" After r293343 clang fails to compile itself with -fsanitize=undefined ( http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_build/). rdar://30259929 llvm-svn: 293475
* [ubsan] Sanity-check shift amounts before truncation (fixes PR27271)Vedant Kumar2017-01-271-2/+2
| | | | | | | | | | | | | Ubsan does not report UB shifts in some cases where the shift exponent needs to be truncated to match the type of the shift base. We perform a range check on the truncated shift amount, leading to false negatives. Fix the issue (PR27271) by performing the range check on the original shift amount. Differential Revision: https://reviews.llvm.org/D29234 llvm-svn: 293343
* Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare ↵Egor Churaev2016-12-231-0/+5
| | | | | | | | | | | | | | operand." Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171 Reviewers: djasper, Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D27981 llvm-svn: 290431
* Revert "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."Daniel Jasper2016-12-201-5/+0
| | | | | | | | | | This reverts commit r290171. It triggers a bunch of warnings, because the new enumerator isn't handled in all switches. We want a warning-free build. Replied on the commit with more details. llvm-svn: 290173
* [OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand.Egor Churaev2016-12-201-0/+5
| | | | | | | | | | | | Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t. Reviewers: Anastasia Subscribers: cfe-commits, yaxunl, bader Differential Revision: https://reviews.llvm.org/D27569 llvm-svn: 290171
* Re-commit r289252 and r289285, and fix PR31374Yaxun Liu2016-12-151-10/+23
| | | | llvm-svn: 289787
* Revert 289252 (and follow-up 289285), it caused PR31374Nico Weber2016-12-141-23/+10
| | | | llvm-svn: 289713
* [clang] Version support for UBSan handlersFilipe Cabecinhas2016-12-121-9/+9
| | | | | | | | | | | | | | | | | | | | | | This adds a way for us to version any UBSan handler by itself. The patch overrides D21289 for a better implementation (we're able to rev up a single handler). After this, then we can land a slight modification of D19667+D19668. We probably don't want to keep all the versions in compiler-rt (maybe we want to deprecate on one release and remove the old handler on the next one?), but with this patch we will loudly fail to compile when mixing incompatible handler calls, instead of silently compiling and then providing bad error messages. Reviewers: kcc, samsonov, rsmith, vsk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D21695 llvm-svn: 289444
* Add two new AST nodes to represent initialization of an array in terms ofRichard Smith2016-12-121-0/+6
| | | | | | | | | | | | | | | | | | | | initialization of each array element: * ArrayInitLoopExpr is a prvalue of array type with two subexpressions: a common expression (an OpaqueValueExpr) that represents the up-front computation of the source of the initialization, and a subexpression representing a per-element initializer * ArrayInitIndexExpr is a prvalue of type size_t representing the current position in the loop This will be used to replace the creation of explicit index variables in lambda capture of arrays and copy/move construction of classes with array elements, and also C++17 structured bindings of arrays by value (which inexplicably allow copying an array by value, unlike all of C++'s other array declarations). No uses of these nodes are introduced by this change, however. llvm-svn: 289413
* Add support for non-zero null pointer for C and OpenCLYaxun Liu2016-12-091-10/+23
| | | | | | | | | | | | | | | | | | In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space. Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value. Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast. Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values. This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way. This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally. Differential Revision: https://reviews.llvm.org/D26196 llvm-svn: 289252
* [OpenCL] Fix bug in __builtin_astype causing invalid LLVM cast instructionsYaxun Liu2016-10-031-3/+52
| | | | | | | | | | | | __builtin_astype is used to cast OpenCL opaque types to other types, as such, it needs to be able to handle casting from and to pointer types correctly. Current it cannot handle 1) casting between pointers of different addr spaces 2) casting between pointer type and non-pointer types. This patch fixes that. Differential Revision: https://reviews.llvm.org/D25123 llvm-svn: 283114
* Re-commit [OpenCL] AMDGCN: Fix size_t typeYaxun Liu2016-08-191-6/+9
| | | | | | There was a premature cast to pointer type in emitPointerArithmetic which caused assertion in tests with assertion enabled. llvm-svn: 279206
* Revert [OpenCL] AMDGCN: Fix size_t typeYaxun Liu2016-08-181-9/+6
| | | | | | due to regressions in test/CodeGen/exprs.c on certain platforms. llvm-svn: 279127
* [OpenCL] AMDGCN: Fix size_t typeYaxun Liu2016-08-181-6/+9
| | | | | | | | Pointers of certain GPUs in AMDGCN target in private address space is 32 bit but pointers in other address spaces are 64 bit. size_t type should be defined as 64 bit for these GPUs so that it could hold pointers in all address spaces. Also fixed issues in pointer arithmetic codegen by using pointer specific intptr type. Differential Revision: https://reviews.llvm.org/D23361 llvm-svn: 279121
* CodeGen: Avoid dereferencing end() in ↵Duncan P. N. Exon Smith2016-08-171-3/+2
| | | | | | | | | | ScalarExprEmitter::EmitOverflowCheckedBinOp Use BB.getNextNode(), which returns nullptr on end(), instead of &*BB.getIterator(), which is UB on end(). CodeGenFunction::createBasicBlock expects nullptr in this case already. llvm-svn: 278898
* Left shifts of negative values are defined if -fwrapv is setJames Molloy2016-08-161-1/+2
| | | | | | | This means we shouldn't emit ubsan detection code or warn. Fixes PR25552. llvm-svn: 278786
* [OpenCL] Handle -cl-fp32-correctly-rounded-divide-sqrtYaxun Liu2016-08-091-2/+7
| | | | | | | | Let the driver pass the option to frontend. Do not set precision metadata for division instructions when this option is set. Set function attribute "correctly-rounded-divide-sqrt-fp-math" based on this option. Differential Revision: https://reviews.llvm.org/D22940 llvm-svn: 278155
* [OpenCL] Generate opaque type for sampler_t and function call for the ↵Yaxun Liu2016-07-281-1/+4
| | | | | | | | | | | | | | | | initializer Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type. This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer. Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions. This patch is partially based on Alexey Sotkin's work in Khronos Clang (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b). Differential Revision: https://reviews.llvm.org/D21567 llvm-svn: 277024
* [CodeGen] Use llvm::Type::getVectorNumElements instead of casting to ↵Craig Topper2016-07-081-2/+2
| | | | | | llvm::VectorType and calling getNumElements. This is equivalent and shorter. llvm-svn: 274823
* [OpenCL] Fix __builtin_astype for vec3 types.Yaxun Liu2016-06-081-38/+36
| | | | | | | | __builtin_astype does not generate correct LLVM IR for vec3 types. This patch inserts bitcasts to/from vec4 when necessary in addition to generating vector shuffle. Sema and codegen tests are added. Differential Revision: http://reviews.llvm.org/D20133 llvm-svn: 272153
* [Sema,CodeGen] Remove comment from SemaChecking about a ↵Craig Topper2016-05-181-18/+2
| | | | | | | | builtin_shufflevector form that it doesn't support. Remove CodeGen support for the same form since it could never have been used due to the missing support in Sema. I couldn't find any documentation that this form existed either. Nor is there documentation for one of the remaining two forms, but there is a testcase that uses it. llvm-svn: 269879
* Enable support for __float128 in Clang and enable it on pertinent platformsNemanja Ivanovic2016-05-091-5/+9
| | | | | | | | | | | | | | | | | | This patch corresponds to reviews: http://reviews.llvm.org/D15120 http://reviews.llvm.org/D19125 It adds support for the __float128 keyword, literals and target feature to enable it. Based on the latter of the two aforementioned reviews, this feature is enabled on Linux on i386/X86 as well as SystemZ. This is also the second attempt in commiting this feature. The first attempt did not enable it on required platforms which caused failures when compiling type_traits with -std=gnu++11. If you see failures with compiling this header on your platform after this commit, it is likely that your platform needs to have this feature enabled. llvm-svn: 268898
* Revert 266186 as it breaks anything that includes type_traits on some platformsNemanja Ivanovic2016-04-151-9/+5
| | | | | | | | | | Since this patch provided support for the __float128 type but disabled it on all platforms by default, some platforms can't compile type_traits with -std=gnu++11 since there is a specialization with __float128. This reverts the patch until D19125 is approved (i.e. we know which platforms need this support enabled). llvm-svn: 266460
* Enable support for __float128 in ClangNemanja Ivanovic2016-04-131-5/+9
| | | | | | | | | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D15120 It adds support for the __float128 keyword, literals and a target feature to enable it. This support is disabled by default on all targets and any target that has support for this type is free to add it. Based on feedback that I've received from target maintainers, this appears to be the right thing for most targets. I have not heard from the maintainers of X86 which I believe supports this type. I will subsequently investigate the impact of enabling this on X86. llvm-svn: 266186
* [OpenCL] Handle AddressSpaceConversion when target address space does not ↵Yaxun Liu2016-04-121-1/+4
| | | | | | | | | | | | | change. In codegen different address spaces may be mapped to the same address space for a target, e.g. in x86/x86-64 all address spaces are mapped to 0. Therefore AddressSpaceConversion should be translated by CreatePointerBitCastOrAddrSpaceCast instead of CreateAddrSpaceCast. Differential Revision: http://reviews.llvm.org/D18713 llvm-svn: 266107
* revert SVN r265702, r265640Saleem Abdulrasool2016-04-081-1/+1
| | | | | | | | | | | Revert the two changes to thread CodeGenOptions into the TargetInfo allocation and to fix the layering violation by moving CodeGenOptions into Basic. Code Generation is arguably not particularly "basic". This addresses Richard's post-commit review comments. This change purely does the mechanical revert and will be followed up with an alternate approach to thread the desired information into TargetInfo. llvm-svn: 265806
OpenPOWER on IntegriCloud