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.
llvm-svn: 78625
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?
llvm-svn: 78547
- Part of optimal static profiling patch sequence by Andreas Neustifter.
- Store edge, block, and function information separately for each functions
(instead of in one giant map).
- Return frequencies as double instead of int, and use a sentinel value for
missing information.
llvm-svn: 78477
I can clean this up a bit more and do way with the TheCondState and just use
the top element on the TheCondStack if not empty. Also may tweak the code
around ParseConditionalAssemblyDirectives() to simplify the AsmParser code.
llvm-svn: 78423
just argv[0]. And remove the code for searching the current
working directory and for searching PATH; the point of FindExecutable
is not to find whatever version of the executable can be found by
searching around, but to find an executable that accompanies the
current executable.
Update the tools to use sys::Program::FindProgramByName when they
want PATH searching.
llvm-svn: 78240
This is not just a matter of passing in the target triple from the module;
currently backends are making decisions based on the build and host
architecture. The goal is to migrate to making these decisions based off of the
triple (in conjunction with the feature string). Thus most clients pass in the
target triple, or the host triple if that is empty.
This has one important change in the way behavior of the JIT and llc.
For the JIT, it was previously selecting the Target based on the host
(naturally), but it was setting the target machine features based on the triple
from the module. Now it is setting the target machine features based on the
triple of the host.
For LLC, -march was previously only used to select the target, the target
machine features were initialized from the module's triple (which may have been
empty). Now the target triple is taken from the module, or the host's triple is
used if that is empty. Then the triple is adjusted to match -march.
The take away is that -march for llc is now used in conjunction with the host
triple to initialize the subtarget. If users want more deterministic behavior
from llc, they should use -mtriple, or set the triple in the input module.
llvm-svn: 77946
- Uses MCAsmToken::getIdentifier which returns the (sub)string representing the
meaningfull contents a string or identifier token.
- Directives aren't done yet.
llvm-svn: 77739
* Call InitializeAllTargets on every path where we might query the
TargetRegistry. This fixes PR4604.
* flush the formatted_raw_ostream& or else not all of the assembly will make
it to the .s file. (It doesn't do this in its destructor?!)
* Due to a reversed conditional, libLTO was reporting many symbols as both
defined and undefined, including two definitions of the same symbol name
in its symbol list.
llvm-svn: 77170
- This is a simplified mechanism which just looks up a target based on the
target triple, with a few additional flags.
- Remove getClosestStaticTargetForModule, the moral equivalent is now:
lookupTarget(Mod->getTargetTriple, true, false, ...);
- This no longer does the fuzzy matching with target data (based on endianness
and pointer width) that getClosestStaticTargetForModule was doing, but this
was deemed unnecessary.
llvm-svn: 77111
- Yay for '-'s and simplifications!
- I kept StringMap::GetOrCreateValue for compatibility purposes, this can
eventually go away. Likewise the StringMapEntry Create functions still follow
the old style.
- NIFC.
llvm-svn: 76888
out of memory, and also make the default memory manager allocate more memory
when it runs out.
Also, switch function stubs and global data over to using the BumpPtrAllocator.
This makes it so the JIT no longer mmaps (or the equivalent on Windows) 16 MB
of memory, and instead allocates in 512K slabs. I suspect this size could go
lower, especially on embedded platforms, now that more slabs can be allocated.
llvm-svn: 76828
the parsing of the .dump and .load should be done in the assembly parser and
not have any need for an MCStreamer API. Changed the code for now so these
just produce an error saying these specific directives are not yet implemented
since they are likely no longer used and may never need to be implemented.
llvm-svn: 76462
"private" symbols which the assember shouldn't strip, but which the linker may
remove after evaluation. This is mostly useful for Objective-C metadata.
This is plumbing, so we don't have a use of it yet. More to come, etc.
llvm-svn: 76385
- Otherwise we get two regressions in llvm-test for applications which run out
of space.
- Once the JIT memory manager is improved, this can be switched back.
llvm-svn: 76291
