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
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
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
pair instead of from a virtual method on TargetMachine. This cuts the final
ties of TargetAsmInfo to TargetMachine, meaning that MC can now use
TargetAsmInfo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78802 91177308-0d34-0410-b5e6-96231b3b80d8
- Used to mark fake instructions which don't correspond to an actual machine
instruction (or are duplicates of a real instruction). This is to be used for
"special cases" in the .td files, which should be ignored by things like the
assembler and disassembler. We still need a good solution to handle pervasive
duplication, like with the Int_ instructions.
- Set the bit on fake "mov 0" style instructions, which allows turning an
assembler matcher warning into a hard error.
- -2 FIXMEs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78731 91177308-0d34-0410-b5e6-96231b3b80d8
version. This allows TAI implementations to specify the directive to use
based on the mode being codegen'd for.
The real fix for this is to remove JumpTableDirective, but I don't feel
like diving into the jumptable snarl just now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78709 91177308-0d34-0410-b5e6-96231b3b80d8
and short. Well, it's kinda short. Definitely nasty and brutish.
The front-end generates the register/unregister calls into the SjLj runtime,
call-site indices and landing pad dispatch. The back end fills in the LSDA
with the call-site information provided by the front end. Catch blocks are
not yet implemented.
Built on Darwin and verified no llvm-core "make check" regressions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78625 91177308-0d34-0410-b5e6-96231b3b80d8
instead of syntactically as a string. This means that it keeps track of the
segment, section, flags, etc directly and asmprints them in the right format.
This also includes parsing and validation support for llvm-mc and
"attribute(section)", so we should now start getting errors about invalid
section attributes from the compiler instead of the assembler on darwin.
Still todo:
1) Uniquing of darwin mcsections
2) Move all the Darwin stuff out to MCSectionMachO.[cpp|h]
3) there are a few FIXMEs, for example what is the syntax to get the
S_GB_ZEROFILL segment type?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78547 91177308-0d34-0410-b5e6-96231b3b80d8
2. Move section switch printing to MCSection virtual method which takes a
TAI. This eliminates textual formatting stuff from TLOF.
3. Eliminate SwitchToSectionDirective, getSectionFlagsAsString, and
TLOFELF::AtIsCommentChar.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78510 91177308-0d34-0410-b5e6-96231b3b80d8
A TAI hook is appropriate in this case because this is just an
asm syntax issue, not a semantic difference. TLOF should model
the semantics of the section.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78498 91177308-0d34-0410-b5e6-96231b3b80d8
driven by TAI to being static, driven by tblgen. This means that a
target doesn't get impacted by this stuff at all if it doesn't opt
into it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78427 91177308-0d34-0410-b5e6-96231b3b80d8
creation activity into the target-specific subclasses of TLOF.
Before this, globals with explicit sections could be created by
the base class.
1. make getOrCreateSection protected, add a new getExplicitSectionGlobal
pure virtual method to assign sections to globals with a specified
section.
2. eliminate getSpecialCasedSectionGlobals, which is now PIC specific.
3. eliminate the getKindForNamedSection virtual method, which is
now just a static method for ELF.
4. Add implementions of getExplicitSectionGlobal for ELF/PECOFF/Darwin/PIC16.
They are now all detangled and understandable, woo! :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78319 91177308-0d34-0410-b5e6-96231b3b80d8
