conversion code do we really need?
- S.append_uint(N) can be replaced with 'raw_svector_ostream(S) << N' which is
somewhat slower due to the extra set up cost, but still plenty fast
(especially if the svector set up cost can be amortized).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79450 91177308-0d34-0410-b5e6-96231b3b80d8
right.
- This class turns out to be much more convenient to use if we do this; clients
can make sure the buffer is always big enough if they care (since our current
idiom tends to be to use a SmallString<256> for the input to this we should
generally be avoiding an unnecessary malloc).
Also, add a convenience raw_svector_ostream::str method which flushes the buffer
and returns a StringRef for the vector contents.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79446 91177308-0d34-0410-b5e6-96231b3b80d8
- This avoids unnecessary malloc/free overhead in the common case, and
unnecessary copying from the ostream buffer into the output vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79434 91177308-0d34-0410-b5e6-96231b3b80d8
- These allow clients to make use of the extra elements in the vector which
have already been allocated, without requiring them to be value initialized.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79433 91177308-0d34-0410-b5e6-96231b3b80d8
gcc-4.4 was optimizing away comparisons against SimpleValueType when
it was compared to a value larger than the largest value in the enum.
This patch works around it by adding one extra item to the enum so
that these tests will now be valid.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79401 91177308-0d34-0410-b5e6-96231b3b80d8
when trying to run opt in parallel. This lets parallel opt crunch 403.gcc in about a third
of the time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79387 91177308-0d34-0410-b5e6-96231b3b80d8
- Kill off begin(), end(), and iterator. It isn't clear what these
mean. Instead provide getBufferStart(), which can be used with
GetNumBytesInBuffer to the same effect.
- Update ComputeColumn to take arguments for the buffer to scan, this
simplifies the implementation of write_impl substantially.
- This should also fix possible problems with the scanning pointer pointing
outside of the current raw_ostream buffer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79379 91177308-0d34-0410-b5e6-96231b3b80d8
- Drop the Candidates argument and fix all callers. Now that RegScavenger
tracks available registers accurately, there is no need to restict the
search.
- Make sure that no aliases of the found register are in use. This was a potential bug.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79369 91177308-0d34-0410-b5e6-96231b3b80d8
TargetData is not present. It still uses TargetData when available.
This generalization also fixed some limitations in the TargetData
case; the attached testcase covers this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79344 91177308-0d34-0410-b5e6-96231b3b80d8
MCAsmStreamer. Based on this, eliminate the current section from AsmPrinter.
While I'm at it, clean up the last of the horrible "switch to null section" stuff
and add an assert. This change is in preparation for completely eliminating
asmprinter::switchtosection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79324 91177308-0d34-0410-b5e6-96231b3b80d8
more properly belong. This allows removing the front-end conditionalized
SJLJ code, and cleans up the generated IR considerably. All of the
infrastructure code (calling _Unwind_SjLj_Register/Unregister, etc) is
added by the SjLjEHPrepare pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79250 91177308-0d34-0410-b5e6-96231b3b80d8
doing it directly. This requires const'izing a bunch of stuff that
took sections, but this seems like the right semantic thing to do:
emitting a label to a section shouldn't mutate the MCSection object
itself, for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79227 91177308-0d34-0410-b5e6-96231b3b80d8
This also adds unit tests to APFloat that mainly tests the
string handling of APFloat, but not much else of it's api.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79210 91177308-0d34-0410-b5e6-96231b3b80d8
support unaligned mem access only for certain types. (Should it be size
instead?)
ARM v7 supports unaligned access for i16 and i32, some v6 variants support it
as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79127 91177308-0d34-0410-b5e6-96231b3b80d8
libcall. Take advantage of this in the ARM backend to rectify broken
choice of CC when hard float is in effect. PIC16 may want to see if
it could be of use in MakePIC16Libcall, which works unchanged.
Patch by Sandeep!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79033 91177308-0d34-0410-b5e6-96231b3b80d8
In order for the changes in r78424 to work properly, cast_retty<X,Y> should return an object instead of a reference, and it's not clear that this approach has real advantages.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79023 91177308-0d34-0410-b5e6-96231b3b80d8
specific printer (this only works on x86, for now).
- This makes it possible to do some correctness checking of the parsing and
matching, since we can compare the results of 'as' on the original input, to
those of 'as' on the output from llvm-mc.
- In theory, we could now have an easy ATT -> Intel syntax converter. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78986 91177308-0d34-0410-b5e6-96231b3b80d8
TargetAsmInfo. This eliminates a dependency on TargetMachine.h from
TargetRegistry.h, which technically was a layering violation.
- Clients probably can only sensibly pass in the same TargetAsmInfo as the
TargetMachine has, but there are only limited clients of this API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78928 91177308-0d34-0410-b5e6-96231b3b80d8
unbuffered. std::ostream does its own buffering, and std::string and
SmallVector both have allocation strategies intended to handle frequent
appending.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78924 91177308-0d34-0410-b5e6-96231b3b80d8
needs of the underlying output mechanism. raw_fd_ostream now uses
st_blksize from fstat to determine a buffer size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78923 91177308-0d34-0410-b5e6-96231b3b80d8
x86_64-apple-darwin10.
--- Reverse-merging r78895 into '.':
U test/CodeGen/PowerPC/2008-12-12-EH.ll
U lib/Target/DarwinTargetAsmInfo.cpp
--- Reverse-merging r78892 into '.':
U include/llvm/Target/DarwinTargetAsmInfo.h
U lib/Target/X86/X86TargetAsmInfo.cpp
U lib/Target/X86/X86TargetAsmInfo.h
U lib/Target/ARM/ARMTargetAsmInfo.h
U lib/Target/ARM/ARMTargetMachine.cpp
U lib/Target/ARM/ARMTargetAsmInfo.cpp
U lib/Target/PowerPC/PPCTargetAsmInfo.cpp
U lib/Target/PowerPC/PPCTargetAsmInfo.h
U lib/Target/PowerPC/PPCTargetMachine.cpp
G lib/Target/DarwinTargetAsmInfo.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78919 91177308-0d34-0410-b5e6-96231b3b80d8
syntactically as a string, very similiar to what Chris did with MachO.
The parsing support and validation is not introduced yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78890 91177308-0d34-0410-b5e6-96231b3b80d8
int x __attribute__((section("_foo, _bar"))) = 4;
int y __attribute__((section("_foo, _bar, 4byte_literals"))) = 1;
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78867 91177308-0d34-0410-b5e6-96231b3b80d8
There have been a few times where I've wanted this but ended up leaving the
operand type unconstrained. It is easy to add this now and should help
catch errors in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78849 91177308-0d34-0410-b5e6-96231b3b80d8
