| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an assembly expression like
bar:
.long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.
The solution used in ELF to use relocation with symbols if there is a non-zero
addend.
In MachO before this patch we would just keep all symbols in some sections.
This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.
This patch implements the non-zero addend logic for MachO too.
llvm-svn: 224985
|
|
|
|
| |
llvm-svn: 224984
|
|
|
|
| |
llvm-svn: 224983
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In a JIT context it is useful to be able to access the GlobalCtors
and especially clear them once they have been emitted and called.
This adds a public method to be able to access the list.
Subscribers: yaron.keren, cfe-commits
Differential Revision: http://reviews.llvm.org/D6790
llvm-svn: 224982
|
|
|
|
|
|
|
|
|
|
| |
Nothing particularly interesting, just adding infrastructure for use by in tree users and out of tree users.
Note: These were extracted out of a working frontend, but they have not been well tested in isolation.
Differential Revision: http://reviews.llvm.org/D6807
llvm-svn: 224981
|
|
|
|
|
|
|
|
|
|
| |
It looks like the original intent was to check which symbols were created.
With macho-dump the sections were being checked just to match which symbol
was in which section.
llvm-objdump prints the section a symbol is in.
llvm-svn: 224980
|
|
|
|
| |
llvm-svn: 224979
|
|
|
|
|
|
|
| |
The OCaml tests require config.llvm_lib_dir to determine
the OCaml package search path.
llvm-svn: 224978
|
|
|
|
|
|
|
|
| |
The latter variable is internal.
Original patch by Ramkumar Ramachandra <artagnon@gmail.com>
llvm-svn: 224977
|
|
|
|
| |
llvm-svn: 224976
|
|
|
|
|
|
|
|
| |
The differences are pretty superficial:
- .lib vs .a extensions
- whether or not to link (potentially) incorrectly against libgcc_s
llvm-svn: 224975
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang tries to produce a helpful diagnostic for the traiilng '...', but the
code that r216778 added for this doesn't expect an invalid trailing return type.
Add code to explicitly handle this.
Having explicit code for this but not for other things looks a bit strange, but
trailing return types are special in that they have a separate existence bit in
addition to the type (see r158348).
llvm-svn: 224974
|
|
|
|
| |
llvm-svn: 224973
|
|
|
|
|
|
|
|
| |
This reverts commit r221445. This change leads to false positives
reports from -fsanitize=vptr. See original commit thread for more
details.
llvm-svn: 224972
|
|
|
|
|
|
|
|
|
|
| |
These are simply a collection of tests intended to show that information about the contents of gc references in the heap is lost at a statepoint. I've tried to write them so that they don't disallow correct transformations, while still being fairly easy to understand.
p.s. Ideas for additional tests are welcome.
Differential Revision: http://reviews.llvm.org/D6491
llvm-svn: 224971
|
|
|
|
|
|
|
|
|
| |
Asserting when building compiler-rt when using a GCC host compiler.
Reverting while I investigate.
This reverts commit r224941.
llvm-svn: 224970
|
|
|
|
|
|
|
|
|
|
|
| |
clang (in r224941)"
Asserting when building compiler-rt when using a gcc host compiler.
Reverting while I investigate.
This reverts commit r224942.
llvm-svn: 224969
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change implements four basic optimizations:
If a relocated value isn't used, it doesn't need to be relocated.
If the value being relocated is null, relocation doesn't change that. (Technically, this might be collector specific. I don't know of one which it doesn't work for though.)
If the value being relocated is undef, the relocation is meaningless.
If the value being relocated was known nonnull, the relocated pointer also isn't null. (Since it points to the same source language object.)
I outlined other planned work in comments.
Differential Revision: http://reviews.llvm.org/D6600
llvm-svn: 224968
|
|
|
|
|
|
| |
That's what I get for last second changes...
llvm-svn: 224967
|
|
|
|
|
|
|
| |
Instead of crashing, recover by eating the extra trailing scope
qualifier. This means we will treat 'struct A:: {' as 'struct A {'.
llvm-svn: 224966
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In LICM, we have a check for an instruction which is guaranteed to execute and thus can't introduce any new faults if moved to the preheader. To handle a function which might unconditionally throw when first called, we check for any potentially throwing call in the loop and give up.
This is unfortunate when the potentially throwing condition is down a rare path. It prevents essentially all LICM of potentially faulting instructions where the faulting condition is checked outside the loop. It also greatly diminishes the utility of loop unswitching since control dependent instructions - which are now likely in the loops header block - will not be lifted by subsequent LICM runs.
define void @nothrow_header(i64 %x, i64 %y, i1 %cond) {
; CHECK-LABEL: nothrow_header
; CHECK-LABEL: entry
; CHECK: %div = udiv i64 %x, %y
; CHECK-LABEL: loop
; CHECK: call void @use(i64 %div)
entry:
br label %loop
loop: ; preds = %entry, %for.inc
%div = udiv i64 %x, %y
br i1 %cond, label %loop-if, label %exit
loop-if:
call void @use(i64 %div)
br label %loop
exit:
ret void
}
The current patch really only helps with non-memory instructions (i.e. divs, etc..) since the maythrow call down the rare path will be considered to alias an otherwise hoistable load. The one exception is that it does kick in for loads which are known to be invariant without regard to other possible stores, i.e. those marked with either !invarant.load metadata of tbaa 'is constant memory' metadata.
Differential Revision: http://reviews.llvm.org/D6725
llvm-svn: 224965
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
multilib build and installs.
Summary:
This requires introducing a generated header to encapsulate the
LLVM_LIBDIR_SUFFIX value from the build system and push it into the go
code. From there, I've adjusted the gllgo code to systematically use
this rather than a raw "lib". This requires some awkwardness as one of
the flags *must* be "lib"-relative for compatibility with how gccgo
works. For that flag, we use ".." to back up a directory and then go
into the proper lib directory.
Differential Revision: http://reviews.llvm.org/D6795
llvm-svn: 224964
|
|
|
|
| |
llvm-svn: 224963
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
down into the cgo-setup variables of llvm-go.
Summary:
This in turn allows us to use #includes with cgo that rely on CMake
provided include directories which is particularly useful for handling
generated headers that aren't reasonable to put in an "installable"
location.
Differential Revision: http://reviews.llvm.org/D6798
llvm-svn: 224962
|
|
|
|
|
|
|
|
|
|
| |
This patches fixes a miscompile where we were assuming that loading from null is undefined and thus we could assume it doesn't happen. This transform is perfectly legal in address space 0, but is not neccessarily legal in other address spaces.
We really should introduce a hook to control this property on a per target per address space basis. We may be loosing valuable optimizations in some address spaces by being too conservative.
Original patch by Thomas P Raoux (submitted to llvm-commits), tests and formatting fixes by me.
llvm-svn: 224961
|
|
|
|
| |
llvm-svn: 224960
|
|
|
|
| |
llvm-svn: 224959
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to r224915. This adds a bit more line noise to the tests
added in that revision to make sure the parser is ready for a toplevel decl
after each incorrect line. Use this to move the tests up to where they belong.
This uncovered that the early return was missing a call to
ActOnTagDefinitionError(), so add that. (Also fixes at least one of the crashes
on SLi's bot.)
llvm-svn: 224958
|
|
|
|
|
|
| |
post-increment circular register stores, and bit reversed post-increment stores.
llvm-svn: 224957
|
|
|
|
|
|
|
|
| |
getMainExecutable() returns a std::string, assigning its result
to StringRef immediately creates a dangling pointer. This was
detected by half-broken fast-MSan-bootstrap bot.
llvm-svn: 224956
|
|
|
|
| |
llvm-svn: 224955
|
|
|
|
|
|
|
| |
More conversion to range based for loops rather than direct iterators with
dereferencing. NFC.
llvm-svn: 224954
|
|
|
|
| |
llvm-svn: 224953
|
|
|
|
|
|
| |
form stores with tests.
llvm-svn: 224952
|
|
|
|
|
|
| |
have encoding bits.
llvm-svn: 224951
|
|
|
|
| |
llvm-svn: 224950
|
|
|
|
|
|
| |
classes and instruction defs.
llvm-svn: 224949
|
|
|
|
|
|
|
| |
Continue to require Python 2 however as recent experiments suggest
LLDB's build requires it.
llvm-svn: 224948
|
|
|
|
|
|
|
|
| |
strings don't mix so easily. This fixes the last remaining failure
I have in 'check-all' on a system with both Python3 and and Python2
installed.
llvm-svn: 224947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Its seems to be replaced by clang_darwin.mk in the Makefile-based
build, and is only referenced in unittest scripts, which are
broken for a long time now.
Test Plan: n/a
Reviewers: bob.wilson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6574
llvm-svn: 224946
|
|
|
|
|
|
|
| |
Let's pretend that we didn't see the '::' instead of go on believing
that we've got some anonymous, but globally qualified, struct.
llvm-svn: 224945
|
|
|
|
|
|
|
| |
Iterate over the arguments via range based for loops rather than iterators and
explicitly dereferencing them. NFC.
llvm-svn: 224944
|
|
|
|
|
|
|
| |
This would've helped stabilize/deflake some failures that were seen
after some recent changes.
llvm-svn: 224943
|
|
|
|
|
|
| |
(in r224941)
llvm-svn: 224942
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).
Original commit message:
This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.
This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.
I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.
Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.
I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.
llvm-svn: 224941
|
|
|
|
|
|
| |
convertible to three address instructions, but aren't really.
llvm-svn: 224940
|
|
|
|
|
|
| |
functionality to the 0x80 opcode instructions, but are not valid in 64-bit mode.
llvm-svn: 224939
|
|
|
|
|
|
| |
for another change. NFC.
llvm-svn: 224938
|
|
|
|
| |
llvm-svn: 224937
|
|
|
|
|
|
| |
Patch by Michael Neumann.
llvm-svn: 224936
|