For better or worse, this is currently the normal error reporting path
when dealing with backend errors from inline assembly. It's not just
internal compiler issues that come through here, so we shouldn't be
creating a backtrace on this path.
rdar://16329947
llvm-svn: 203979
Summary:
The sample profiler pass emits several error messages. Instead of
just aborting the compiler with report_fatal_error, we can emit
better messages using DiagnosticInfo.
This adds a new sub-class of DiagnosticInfo to handle the sample
profiler.
Reviewers: chandlerc, qcolombet
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3086
llvm-svn: 203976
any lexical scopes then go ahead and turn on DW_AT_ranges for the
compile unit since we would be claiming to describe in the CU
a range for which we don't have information in the CU otherwise.
llvm-svn: 203969
This sometimes remains null into MCLineTableHeader::Emit where we
conditionally construct a label if one isn't provided for us. We need it
to remain null (rather than just always constructing the label) so we
can identify unused line tables... which is a bit weird and maybe we can
do away with that logic one day (& on that day we can always construct
the label up-front and just have compilation units query the line table
for its label, etc)
llvm-svn: 203967
This change brings getCallPreservedMask()'s logic in line with
getCalleeSavedRegs().
While this changes the control flow slightly, the change is not
currently observable. is64Bit must be false to get to the accidental
fallthrough, but the case that we fall into (coldcc) does nothing unless
is64Bit is true.
llvm-svn: 203943
sys::fs::createUniqueFile returns an absolute path, so MakeSharedObject does
too and we don't need to add a './' prefix.
Patch by Jon McLachlan.
llvm-svn: 203931
The idea behind this split of ValueTypes.h, is to make it easier to
ensure that stuff after type legalization only use MVT (rather than
EVT), by watching include dependencies.
Reviewed By: Tim Northover
llvm-svn: 203926
Commit r181723 introduced code to avoid placing initialized variables
needing relocations into the .rodata section, which avoid copy relocs
that do not work as expected on ppc64 function references.
The same treatment is also needed for *named* .rodata.XXX sections.
This patch changes PPC64LinuxTargetObjectFile::SelectSectionForGlobal
to modify "Kind" *before* calling the default SelectSectionForGlobal
routine, instead of first calling the default routine and then just
checking for the (main) .rodata section afterwards.
llvm-svn: 203921
issue in that the new MachineRegisterInfo bundle iterators didn't
dereference to the START of the bundle, while the old skipBundle()
method did.
llvm-svn: 203890
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:
* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.
It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.
With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.
The objc uses are currently split in
* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.
The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are
* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.
Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.
For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).
llvm-svn: 203866
operator* on the by-operand iterators to return a MachineOperand& rather than
a MachineInstr&. At this point they almost behave like normal iterators!
Again, this requires making some existing loops more verbose, but should pave
the way for the big range-based for-loop cleanups in the future.
llvm-svn: 203865
When initializing an iterator, we may have to step forward to find the first
operand that passes the current filter set. When doing that stepping, we should
always step one operand at a time, even if this is by-instr or by-bundle iterator,
as we're stepping between invalid values, so the stride doesn't make sense there.
Fixes a miscompilation of YASM on Win32 reported by Hans Wennborg. I have not
yet figured out how to reduce it to something testcase-able, because it's sensitive
to the details of how the registers get spilled.
llvm-svn: 203852
