Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

llvm-gcc doesn't take advantage of __const_coal section on darwin #2855

Closed
lattner opened this issue Jun 21, 2008 · 11 comments
Closed

llvm-gcc doesn't take advantage of __const_coal section on darwin #2855

lattner opened this issue Jun 21, 2008 · 11 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla

Comments

@lattner
Copy link
Collaborator

lattner commented Jun 21, 2008

Bugzilla Link 2483
Resolution FIXED
Resolved on Nov 07, 2018 00:22
Version unspecified
OS All
CC @asl,@isanbard

Extended Description

Building instcombine at -O0 -g with llvm-gcc, nothing is emitted into the __const_coal section. With GCC, it emits:

Section (__DATA, __const_coal): 48
Section (__TEXT, __const_coal): 128

I don't know what this section is, but if useful, we should use it. :)

@lattner
Copy link
Collaborator Author

lattner commented Jun 21, 2008

assigned to @asl

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 26, 2008

This differs between gcc-4.2 and gcc-4.0.

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 26, 2008

The darwin assembler only allows weak definition symbols (.weak_definition) on symbols in S_COALESCED sections. The __const_coal section is usually constructed that way. The constraint comes from an early implementation of coalescing that pre-dates how darwin tools now processes weak symbols.

I've been trying to remove this restriction in the assembler, but that will take a while.

What llvm should do, is if it is going to emit a function/data into the __const section and the symbol is a weak definition, it should switch to the __const_coal section.

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 26, 2008

gcc-4.2 puts
typeinfo name for llvm::InstVisitor<(anonymous namespace)::InstCombiner, llvm::Instruction*>
in TEXT,__const_coal. This symbol is not weak. That's it.

llvm-gcc-4.2 puts that object in .cstring. gcc-4.2 puts other typeinfo names in .cstring; it's not obvious what algorithm to use to pick.

gcc-4.0 puts
typeinfo for llvm::InstVisitor<(anonymous namespace)::InstCombiner, llvm::Instruction*>
vtable for llvm::CmpInst
typeinfo for llvm::CmpInst
in DATA, const_coal. It puts
typeinfo name for llvm::InstVisitor<(anonymous namespace)::InstCombiner, llvm::Instruction*>
typeinfo name for llvm::CmpInst
in TEXT, const_coal. All these are weak globals. (The mangling for the 4th symbol, which also appears in gcc-4.2, is different from that in gcc-4.2.)

@asl
Copy link
Collaborator

asl commented Jul 2, 2008

What llvm should do, is if it is going to emit a function/data into the __const
section and the symbol is a weak definition, it should switch to the
__const_coal section.
This will be really easy in the new section name handling infrastructure I'm working on.

@asl
Copy link
Collaborator

asl commented Jul 9, 2008

The support was added in recent series of patches. Please check.

@asl
Copy link
Collaborator

asl commented Sep 29, 2008

Ping :)

@llvmbot
Copy link
Collaborator

llvmbot commented Oct 9, 2008

llvm-gcc-4.2's use of this section has not changed on InstCombine in TOT, so we don't match either gcc-4.0 or gcc-4.2 behaviors, which are different. But from Nick's comment, neither gcc-4.0 nor gcc-4.2 is doing the right thing anyway. There is no weak data in this file (only functions), so I think it is not supposed to be using __const_coal. But I confess I find the situation confusing.

@asl
Copy link
Collaborator

asl commented Aug 31, 2010

Is this still an issue?

@lattner
Copy link
Collaborator Author

lattner commented Aug 31, 2010

Dale, please take a look to see if we're missing anything useful here, if not, please close this, thanks!

@llvmbot
Copy link
Collaborator

llvmbot commented Aug 31, 2010

I don't believe "correct" is well defined here (or I don't understand the definition), but I think the behavior matches what Nick describes, which should be OK.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla
Projects
None yet
Development

No branches or pull requests

3 participants