This is essentially reverting one piece of 184793 to try to fix one of Apple's
buildbots. I will check with Eric to see if this is OK or if we need to find
some other solution.
llvm-svn: 185060
There are a few valid situation where we care about the structure inside a
directory, but not about the directory itself. A simple example is for unit
testing directory traversal.
PathV1 had a function like this, add one to V2 and port existing users of the
created temp file and delete it hack to using it.
llvm-svn: 185059
When we store values for reversed induction stores we must not store the
reversed value in the vectorized value map. Another instruction might use this
value.
This fixes 3 test cases of PR16455.
llvm-svn: 185051
The Builtin attribute is an attribute that can be placed on function call site that signal that even though a function is declared as being a builtin,
rdar://problem/13727199
llvm-svn: 185049
Currently inside APFloat fcNormal still implies the old definition of Normal
(i.e. isFiniteNonZero) instead of the proper IEEE-754R definition that the
external method isNormal() uses.
This patch prepares for the internal switch inside APFloat by converting all
references that check if a category is fcNormal directly with an indirect call
via isFiniteNonZero().
llvm-svn: 185036
Option groups don't have prefixes. Option dumping is basically dead
code unless there is something wrong with the option table, so this
isn't an important crasher.
llvm-svn: 185031
(Currently, ARM 'this'-returns are handled in the standard calling convention case by treating R0 as preserved and doing some extra magic in LowerCallResult; this may not apply to calling conventions added in the future so this patch provides and documents an interface for indicating such)
llvm-svn: 185024
Unfortunately this addresses two issues (by the time I'd disentangled the logic
it wasn't worth putting it back to half-broken):
+ Coprocessor instructions should all be predicable in Thumb mode.
+ BKPT should never be predicable.
llvm-svn: 184965
The assembler currently strictly verifies that immediates for
s16imm operands are in range (-32768 ... 32767). This matches
the behaviour of the GNU assembler, with one exception: gas
allows, as a special case, operands in an extended range
(-65536 .. 65535) for the addis instruction only (and its
extended mnemonic lis).
The main reason for this seems to be to allow using unsigned
16-bit operands for lis, e.g. like lis %r1, 0xfedc.
Since this has been supported by gas for a long time, and
assembler source code seen "in the wild" actually exploits
this feature, this patch adds equivalent support to LLVM
for compatibility reasons.
llvm-svn: 184946
Currently, all instructions taking s16imm operands support symbolic
operands. However, for u16imm operands, we only support actual
immediate integers. This causes the assembler to reject code like
ori %r5, %r5, symbol@l
This patch changes the u16imm operand definition to likewise
accept symbolic operands. In fact, s16imm and u16imm can
share the same encoding routine, now renamed to getImm16Encoding.
llvm-svn: 184944
Where a source tree is complete with lld, lldb and polly, it may not be possible to use cmake to configure build scripts if the host compiler it not capable of compiling these sub-projects. This change makes it possible to first build a bootstrap clang compiler when can then be used to build a complete llvm toolchain. An example bootstrap build sequence could be as follows:
$ mkdir bootstrap
$ cd bootstrap
$ cmake -G 'Unix Makefiles'
-DCMAKE_BUILD_TYPE:STRING=Release
-DCMAKE_PREFIX_PATH:STRING=$(pwd)
-DLLVM_TARGETS_TO_BUILD:STRING=host
-DLLVM_INCLUDE_TOOLS:STRING=bootstrap-only
../source
$ make clang # build clang only for host
$ cd ..
$ export CC=$(realpath bootstrap/bin)/clang
$ export CXX=$(realpath bootstrap/bin)/clang++
$ mkdir final
$ cd final
$ cmake -G 'Unix Makefiles' ../source
$ make all check-all
llvm-svn: 184924
