[llvm-commits] [llvm] r76666 - /llvm/trunk/lib/Target/XCore/XCoreTargetAsmInfo.cpp

[Chris Lattner]

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