[llvm-commits] [llvm] r76666 - /llvm/trunk/lib/Target/XCore/XCoreTargetAsmInfo.cpp
Chris Lattner
clattner at apple.com
Wed Jul 22 09:49:01 PDT 2009
On Jul 22, 2009, at 3:43 AM, Richard Osborne wrote:
> Chris Lattner wrote:
> On the XCore the small section flag "s" is not supported but there are
> two other non standard section flags which must be emitted by the
> backend.
Ok. One of my general "gripes" about the current system (which I'm
working on hopefully fixing) is that the section flags are all very
ELF-specific. This doesn't help darwin, doesn't help Xcore, and
doesn't help COFF targets like windows. I'd like to move to a world
where the target can use the ELF flags, Darwin flags, COFF flags, and
add its own set of target-specific flags as well. This should
hopefully give you a better solution than abusing the 'small' flag :).
> Data is normally accessed relative to either the cp or dp
> registers. All sections with the "c" flag are grouped together by the
> linker to form the constant pool and the cp register is set to the
> start
> of the constant pool by the boot code. Similarly all sections with the
> "d" flag are grouped together to form the data region and the dp
> register is set to the start of the region. The code generated to
> access
> the global is different depending whether the global is placed in
> the cp
> or dp. If the there is a mismatch between the code to access the
> global
> and the section flags for the global the linker will error when it
> tries
> to apply relocations.
Ok, this sounds very much like the mess I recently cleaned up in the
X86 backend where ISel would have to know exactly how relocations and
addressing were performed for a global, and then the asmprinter (and
many other parts of the code) would have to reinfer how it worked in
slightly different ways :).
Can you please add some example .ll files to test/CodeGen/XCore that
illustrate these sorts of idioms and uses FileCheck to verify that the
code generator is doing the right thing? I can't really preserve
current behavior without testing, and I don't have XCore hardware
lying around :).
> The SectionFlags::Small was being used (misused?) to represent these
> flags. Whether the frontend set SectionFlags::Small was being ignored
> and instead SectionFlags::Writable and SectionFlags::Small were being
> used represent the "d" flag and SectionFlags::Small on its own was
> used
> to represent the "c" flag.
>
> It would be nice if there was a mechanism to specify target specific
> sections flags for a section, but I don't think this exists at the
> moment. As things stand these changes will break things on the XCore
> since the "c" and "d" flags will no longer be emitted.
Ok. Please add some testcases (xfailed if needbe) and I'll work on
fixing this. It sounds like it should fall out nicely from the rest
of the cleanup I'm working on. Is the tree currently in a working
state for you, or is it broken? I see uses of SectionFlags::Small in
XCoreTargetAsmInfo::XCoreTargetAsmInfo, I don't know if that is enough
to make things work for you. If not, is it ok for me to remove those?
-Chris
More information about the llvm-commits
mailing list