llvm-svn: 55901

llvm-svn: 55900

Reduce heap trashing due to std::string construction / concatenation via caching of section flags string representations

llvm-svn: 54842

llvm-svn: 54542

llvm-svn: 53789

llvm-svn: 53788

constant pool, if relocation model is not static. This directly maps to
the way how GCC works.

llvm-svn: 53370

llvm-svn: 53368

llvm-svn: 53354

llvm-svn: 53350

llvm-svn: 53340

llvm-svn: 53324

llvm-svn: 53322

llvm-svn: 53320

llvm-svn: 53319

llvm-svn: 53318

llvm-svn: 53315

llvm-svn: 53314

llvm-svn: 53313

llvm-svn: 53312

llvm-svn: 53311

llvm-svn: 53307

llvm-svn: 53306

llvm-svn: 53305

llvm-svn: 53304

llvm-svn: 53303

llvm-svn: 53302

llvm-svn: 53301

llvm-svn: 53300

llvm-svn: 53299

llvm-svn: 53298

llvm-svn: 53297

llvm-svn: 53296

llvm-svn: 53295

moves in order to get correct debug info.  Since
I can't imagine how any target could possibly
be any different, I've just stripped out the
option: now all the world's like Darwin!

llvm-svn: 53134

debug information is being output, because it's leet!

llvm-svn: 52994

assembler names of string constants look like.

llvm-svn: 51909

on x86-64 linux.  This causes no regressions on
32 bit linux and 32 bit ppc.  More tests pass
on 64 bit ppc with no regressions.  I didn't
turn on eh on 64 bit linux because the intrinsics
needed to compile the eh runtime aren't done
yet.  But if you turn it on and link with the
mainline runtime then eh seems to work fine
on x86-64 linux with this patch.  Thanks to
Dale for testing.  The main point of the patch
is that if you output that some object is
encoded using 4 bytes you had better not output
8 bytes for it: the patch makes everything
consistent.

llvm-svn: 50825

llvm-svn: 50649

the code being generated does not require an executable stack.

Also, add target-specific code to make use of this on Linux
on x86. 

llvm-svn: 50634