Now that PowerPC no longer uses adjustFixupOffset, and no other
back-end (ever?) did, we can remove the infrastructure itself
(incidentally addressing a FIXME to that effect).
llvm-svn: 181895
Now that applyFixup understands differently-sized fixups, we can define
fixup_ppc_lo16/fixup_ppc_lo16_ds/fixup_ppc_ha16 to properly be 2-byte
fixups, applied at an offset of 2 relative to the start of the
instruction text.
This has the benefit that if we actually need to generate a real
relocation record, its address will come out correctly automatically,
without having to fiddle with the offset in adjustFixupOffset.
Tested on both 64-bit and 32-bit PowerPC, using external and
integrated assembler.
llvm-svn: 181894
The PPCAsmBackend::applyFixup routine handles the case where a
fixup can be resolved within the same object file. However,
this routine is currently hard-coded to assume the size of
any fixup is always exactly 4 bytes.
This is sort-of correct for fixups on instruction text; even
though it only works because several of what really would be
2-byte fixups are presented as 4-byte fixups instead (requiring
another hack in PPCELFObjectWriter::adjustFixupOffset to clean
it up).
However, this assumption breaks down completely for fixups
on data, which legitimately can be of any size (1, 2, 4, or 8).
This patch makes applyFixup aware of fixups of varying sizes,
introducing a new helper routine getFixupKindNumBytes (along
the lines of what the ARM back end does). Note that in order
to handle fixups of size 8, we also need to fix the return type
of adjustFixupValue to uint64_t to avoid truncation.
Tested on both 64-bit and 32-bit PowerPC, using external and
integrated assembler.
llvm-svn: 181891
Before:
namespace abc { class SomeClass; }
namespace def { void someFunction() {} }
After:
namespace abc {
class Def;
}
namespace def {
void someFunction() {}
}
Rationale:
a) Having anything other than forward declaration on the same line
as a namespace looks confusing.
b) Formatting namespace-forward-declaration-combinations different
from other stuff is inconsistent.
c) Wasting vertical space close to such forward declarations really
does not affect readability.
llvm-svn: 181887
This commit improves Clang's diagnostics for string initialization.
Where it would previously say:
/tmp/a.c:3:9: error: array initializer must be an initializer list
wchar_t s[] = "Hi";
^
/tmp/a.c:4:6: error: array initializer must be an initializer list or string literal
char t[] = L"Hi";
^
It will now say
/tmp/a.c:3:9: error: initializing wide char array with non-wide string literal
wchar_t s[] = "Hi";
^
/tmp/a.c:4:6: error: initializing char array with wide string literal
char t[] = L"Hi";
^
As a bonus, it also fixes the fact that Clang would previously reject
this valid C11 code:
char16_t s[] = u"hi";
char32_t t[] = U"hi";
because it would only recognize the built-in types for char16_t and
char32_t, which do not exist in C.
llvm-svn: 181880
The function type detection in r181438 and r181764 detected function
types too eagerly. This led to inconsistent formatting of inline
assembly and (together with r181687) to an incorrect formatting of calls
in macros.
Before: #define DEREF_AND_CALL_F(parameter) f (*parameter)
After: #define DEREF_AND_CALL_F(parameter) f(*parameter)
llvm-svn: 181870
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.
One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).
llvm-svn: 181869
BitVector/SmallBitVector::reference::operator bool remain implicit since
they model more exactly a bool, rather than something else that can be
boolean tested.
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
One behavior change (YAMLParser) was made, though no test case is
included as I'm not sure how to reach that code path. Essentially any
comparison of llvm::yaml::document_iterators would be invalid if neither
iterator was at the end.
This helped uncover a couple of bugs in Clang - test cases provided for
those in a separate commit along with similar changes to `operator bool`
instances in Clang.
llvm-svn: 181868
Python breakpoint actions can return False to say that they don't want to stop at the breakpoint to which they are associated
Almost all of the work to support this notion of a breakpoint callback was in place, but two small moving parts were missing:
a) the SWIG wrapper was not checking the return value of the script
b) when passing a Python function by name, the call statement was dropping the return value of the function
This checkin addresses both concerns and makes this work
Care has been taken that you only keep running when an actual value of False has been returned, and that any other value (None included) means Stop!
llvm-svn: 181866
These intrinsics use the __builtin_shuffle() function to extract the
low and high half, respectively, of a 128-bit NEON vector. Currently,
they're defined to use bitcasts to simplify the emitter, so we get code
like:
uint16x4_t vget_low_u32(uint16x8_t __a) {
return (uint32x2_t) __builtin_shufflevector((int64x2_t) __a,
(int64x2_t) __a,
0);
}
While this works, it results in those bitcasts going all the way through
to the IR, resulting in code like:
%1 = bitcast <8 x i16> %in to <2 x i64>
%2 = shufflevector <2 x i64> %1, <2 x i64> undef, <1 x i32>
%zeroinitializer
%3 = bitcast <1 x i64> %2 to <4 x i16>
We can instead easily perform the operation directly on the input vector
like:
uint16x4_t vget_low_u16(uint16x8_t __a) {
return __builtin_shufflevector(__a, __a, 0, 1, 2, 3);
}
Not only is that much easier to read on its own, it also results in
cleaner IR like:
%1 = shufflevector <8 x i16> %in, <8 x i16> undef,
<4 x i32> <i32 0, i32 1, i32 2, i32 3>
This is both easier to read and easier for the back end to reason
about effectively since the operation is obfuscating the source with
bitcasts.
rdar://13894163
llvm-svn: 181865
It should fix llvm/test/CodeGen/ARM/ehabi-mc-compact-pr*.ll on some hosts.
RELOCATION RECORDS FOR [.ARM.exidx]:
0 R_ARM_PREL31 .text
0 R_ARM_NONE __aeabi_unwind_cpp_pr0
FIXME: I am not sure of the directions of extra comparators, in Type and Index.
For now, they are different from the direction in r_offset.
llvm-svn: 181864
process StopLocker (if there is a process) before it will hand out SBValues. We were doing this in
an ad hoc fashion previously, and then playing whack-a-mole whenever we found a place where we should
have been doing this but weren't. Really, it doesn't make sense to be poking at SBValues when the target
is running, the dynamic and synthetic values can't really be computed, and the underlying memory may be
incoherent.
<rdar://problem/13819378> Sometimes when stepping fast, my inferior is killed by debugserver
llvm-svn: 181863
InstCombine can be uncooperative to vectorization and sink loads into
conditional blocks. This prevents vectorization.
Undo this optimization if there are unconditional memory accesses to the same
addresses in the loop.
radar://13815763
llvm-svn: 181860
This is expanding Ben's original heuristic for short basic blocks to
also work for longer basic blocks and huge use lists.
Scan the basic block and the use list in parallel, terminating the
search when the shorter list ends. In almost all cases, either the basic
block or the use list is short, and the function returns quickly.
In one crazy test case with very long use chains, CodeGenPrepare runs
400x faster. When compiling ARMDisassembler.cpp it is 5x faster.
<rdar://problem/13840497>
llvm-svn: 181851
found for a receiver, note where receiver class
is declaraed (this is most common when receiver is a forward
class). // rdar://3258331
llvm-svn: 181847
There were two problems that made llvm-objdump -r crash:
- for non-scattered relocations, the symbol/section index is actually in the
(aptly named) symbolnum field.
- sections are 1-indexed.
llvm-svn: 181843
Fariborz Jahanian