History log of /llvm-project/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp (Results 351 – 375 of 536)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 29786d4c 12-Feb-2015 Rafael Espindola <rafael.espindola@gmail.com>

Put each jump table in an independent section if the function is too.

This allows the linker to GC both, fixing pr22557.

llvm-svn: 228937


# 25d2c20c 11-Feb-2015 Rafael Espindola <rafael.espindola@gmail.com>

Don't repeat name in comment and clang-format a function.

llvm-svn: 228831


# f8d662aa 05-Feb-2015 Rafael Espindola <rafael.espindola@gmail.com>

Add a FIXME.

Thanks to Eric for the suggestion.

llvm-svn: 228300


# a092f175 04-Feb-2015 Rafael Espindola <rafael.espindola@gmail.com>

Don' try to make sections in comdats SHF_MERGE.

Parts of llvm were not expecting it and we wouldn't print
the entity size of the section.

Given what comdats are used for, having SHF_MERGE sections

Don' try to make sections in comdats SHF_MERGE.

Parts of llvm were not expecting it and we wouldn't print
the entity size of the section.

Given what comdats are used for, having SHF_MERGE sections would be
just a small improvement, so just disable it for now.

Fixes pr22463.

llvm-svn: 228196

show more ...


Revision tags: llvmorg-3.6.0-rc2
# ba31e27f 29-Jan-2015 Rafael Espindola <rafael.espindola@gmail.com>

Compute the ELF SectionKind from the flags.

Any code creating an MCSectionELF knows ELF and already provides the flags.

SectionKind is an abstraction used by common code that uses a plain
MCSection

Compute the ELF SectionKind from the flags.

Any code creating an MCSectionELF knows ELF and already provides the flags.

SectionKind is an abstraction used by common code that uses a plain
MCSection.

Use the flags to compute the SectionKind. This removes a lot of
guessing and boilerplate from the MCSectionELF construction.

llvm-svn: 227476

show more ...


# 093dcc43 29-Jan-2015 Rafael Espindola <rafael.espindola@gmail.com>

Use isMergeableConst now that it is sane.

llvm-svn: 227441


# fad39010 29-Jan-2015 Rafael Espindola <rafael.espindola@gmail.com>

Don't create multiple mergeable sections with -fdata-sections.

ELF has support for sections that can be split into fixed size or
null terminated entities.

Since these sections can be split by the l

Don't create multiple mergeable sections with -fdata-sections.

ELF has support for sections that can be split into fixed size or
null terminated entities.

Since these sections can be split by the linker, it is not necessary
to split them in codegen.

This reduces the combined .o size in a llvm+clang build from
202,394,570 to 173,819,098 bytes.

The time for linking clang with gold (on a VM, on a laptop) goes
from 2.250089985 to 1.383001792 seconds.

The flip side is the size of rodata in clang goes from 10,926,785
to 10,929,345 bytes.

The increase seems to be because of http://sourceware.org/bugzilla/show_bug.cgi?id=17902.

llvm-svn: 227431

show more ...


# a05b3b73 28-Jan-2015 Rafael Espindola <rafael.espindola@gmail.com>

Simplify code. NFC.

llvm-svn: 227333


# 8b770651 26-Jan-2015 Eric Christopher <echristo@gmail.com>

Move DataLayout back to the TargetMachine from TargetSubtargetInfo
derived classes.

Since global data alignment, layout, and mangling is often based on the
DataLayout, move it to the TargetMachine.

Move DataLayout back to the TargetMachine from TargetSubtargetInfo
derived classes.

Since global data alignment, layout, and mangling is often based on the
DataLayout, move it to the TargetMachine. This ensures that global
data is going to be layed out and mangled consistently if the subtarget
changes on a per function basis. Prior to this all targets(*) have
had subtarget dependent code moved out and onto the TargetMachine.

*One target hasn't been migrated as part of this change: R600. The
R600 port has, as a subtarget feature, the size of pointers and
this affects global data layout. I've currently hacked in a FIXME
to enable progress, but the port needs to be updated to either pass
the 64-bitness to the TargetMachine, or fix the DataLayout to
avoid subtarget dependent features.

llvm-svn: 227113

show more ...


# 12ca34f5 19-Jan-2015 Rafael Espindola <rafael.espindola@gmail.com>

Bring r226038 back.

No change in this commit, but clang was changed to also produce trivial comdats when
needed.

Original message:

Don't create new comdats in CodeGen.

This patch stops the implic

Bring r226038 back.

No change in this commit, but clang was changed to also produce trivial comdats when
needed.

Original message:

Don't create new comdats in CodeGen.

This patch stops the implicit creation of comdats during codegen.

Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now produce the same result in pr19848.

llvm-svn: 226467

show more ...


# 60b72136 16-Jan-2015 Timur Iskhodzhanov <timurrrr@google.com>

Revert r226242 - Revert Revert Don't create new comdats in CodeGen

This breaks AddressSanitizer (ninja check-asan) on Windows

llvm-svn: 226251


# 67a79e72 16-Jan-2015 Rafael Espindola <rafael.espindola@gmail.com>

Revert "Revert Don't create new comdats in CodeGen"

This reverts commit r226173, adding r226038 back.

No change in this commit, but clang was changed to also produce trivial comdats for
costructors

Revert "Revert Don't create new comdats in CodeGen"

This reverts commit r226173, adding r226038 back.

No change in this commit, but clang was changed to also produce trivial comdats for
costructors, destructors and vtables when needed.

Original message:

Don't create new comdats in CodeGen.

This patch stops the implicit creation of comdats during codegen.

Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now produce the same result in pr19848.

llvm-svn: 226242

show more ...


# f5adf13f 15-Jan-2015 Timur Iskhodzhanov <timurrrr@google.com>

Revert Don't create new comdats in CodeGen

It breaks AddressSanitizer on Windows.

llvm-svn: 226173


Revision tags: llvmorg-3.6.0-rc1
# fad1639a 14-Jan-2015 Rafael Espindola <rafael.espindola@gmail.com>

Don't create new comdats in CodeGen.

This patch stops the implicit creation of comdats during codegen.

Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now pr

Don't create new comdats in CodeGen.

This patch stops the implicit creation of comdats during codegen.

Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now produce the same result in pr19848.

llvm-svn: 226038

show more ...


# 1e923ec1 09-Jan-2015 Lang Hames <lhames@gmail.com>

Recommit r224935 with a fix for the ObjC++/AArch64 bug that that revision
introduced.

A test case for the bug was already committed in r225385.

Patch by Rafael Espindola.

llvm-svn: 225534


# 66f755f8 06-Jan-2015 Lang Hames <lhames@gmail.com>

Revert r224935 "Refactor duplicated code. No intended functionality change."

This is affecting the behavior of some ObjC++ / AArch64 test cases on Darwin.
Reverting to get the bots green while I tra

Revert r224935 "Refactor duplicated code. No intended functionality change."

This is affecting the behavior of some ObjC++ / AArch64 test cases on Darwin.
Reverting to get the bots green while I track down the source of the changed
behavior.

llvm-svn: 225311

show more ...


# c43b0633 30-Dec-2014 Michael Kuperstein <michael.m.kuperstein@intel.com>

[COFF] Don't try to add quotes to already quoted linker directives

If a linker directive is already quoted, don't try to quote it again, otherwise it creates a mess.
This pops up in places like:
#pr

[COFF] Don't try to add quotes to already quoted linker directives

If a linker directive is already quoted, don't try to quote it again, otherwise it creates a mess.
This pops up in places like:
#pragma comment(linker,"\"/foo bar'\"")

Differential Revision: http://reviews.llvm.org/D6792

llvm-svn: 224998

show more ...


# bed67f3a 29-Dec-2014 Rafael Espindola <rafael.espindola@gmail.com>

Refactor duplicated code.

No intended functionality change.

llvm-svn: 224935


Revision tags: llvmorg-3.5.1, llvmorg-3.5.1-rc2
# 5bf8fef5 09-Dec-2014 Duncan P. N. Exon Smith <dexonsmith@apple.com>

IR: Split Metadata from Value

Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the I

IR: Split Metadata from Value

Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.

I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.

This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.

Here's a quick guide for updating your code:

- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.

- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).

- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.

If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.

- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.

As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)

If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.

- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).

As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.

The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).

In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:

MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));

you can trivially match its semantics with:

MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));

and when you transition your metadata schema to `MDInt`:

MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));

- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.

`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.

(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)

llvm-svn: 223802

show more ...


Revision tags: llvmorg-3.5.1-rc1
# c98ec0e7 21-Nov-2014 Manman Ren <manman.ren@gmail.com>

[Objective-C] Support a new special module flag that will be put into the
objc_imageinfo struct.

rdar://17954668

llvm-svn: 222558


# 83f0ea89 06-Nov-2014 Rafael Espindola <rafael.espindola@gmail.com>

Add three other sections when L symbols are allowed.

llvm-svn: 221436


# bf77ed68 06-Nov-2014 Rafael Espindola <rafael.espindola@gmail.com>

Allow L symbols in no_dead_strip sections.

If a section cannot be dead stripped, it is safe to use L symbols, since
the linker will keep all of it in the end.

llvm-svn: 221431


# 597be2de 22-Sep-2014 David Majnemer <david.majnemer@gmail.com>

MC: ReadOnlyWithRel section kinds should map to rdata in COFF

Don't consider ReadOnlyWithRel as a writable section in COFF, they
really belong in .rdata.

llvm-svn: 218268


# b8dbebb3 20-Sep-2014 David Majnemer <david.majnemer@gmail.com>

MC: Treat ReadOnlyWithRel and ReadOnlyWithRelLocal as ReadOnly for COFF

A problem with our old behavior becomes observable under x86-64 COFF
when we need a read-only GV which has an initializer whic

MC: Treat ReadOnlyWithRel and ReadOnlyWithRelLocal as ReadOnly for COFF

A problem with our old behavior becomes observable under x86-64 COFF
when we need a read-only GV which has an initializer which is referenced
using a relocation: we would mark the section as writable. Marking the
section as writable interferes with section merging.

This fixes PR21009.

llvm-svn: 218179

show more ...


# c0f0c511 19-Sep-2014 Hans Wennborg <hans@hanshq.net>

Fix an it's vs. its typo.

llvm-svn: 218093


1...<<11121314151617181920>>...22