<div dir="ltr"><font face="monospace, monospace">I've prepared a preliminary patch with the intention of implementing PPC-EABI subtarget features for applications that run in a standalone embedded environment.<br><br><a href="https://reviews.llvm.org/D26344">https://reviews.llvm.org/D26344</a><br><br>The most significant difference compared with the SVR4 ABI is the use of SDA (small data area). This allows full-word constants and data to be grouped into small-data sections accessed using relocated addresses; calculated relative to the non-volatile values loaded into base registers r13 and r2 by the runtime init (similar to gp_rel on MIPS). Only a single load/store instruction is needed to contain the relocated address.<br><br>The MIPS target already has a solid approach for handling small global variables in its TargetLoweringObjectFile subclass. Also, the clang driver responds to the `-G <bytes>` flag so the user can define a cutoff size other than 8 (or 0 to disable small data altogether).<br><br>It seems the Hexagon and Lanai targets duplicate much of the IsGlobalInSmallSection handling from the MIPS target, but perform the same basic classification tasks:<br><br>1. Pass GlobalObject to target-declared IsGlobalInSmallSection. </font><div><font face="monospace, monospace">   If it's a declaration, skip to step 4.<br>2. Pass GlobalObject to target-independent </font></div><div><font face="monospace, monospace">   TargetLoweringObjectFile::getKindForGlobal.<br>3. Ensure the returned SectionKind is Data, BSS or Common.<br>4. Pass GlobalObject to target-specific IsGlobalInSmallSectionImpl, </font></div><div><font face="monospace, monospace">   which scrutinizes the object's type for the specific architecture.<br><br>I believe this redundant implementation between targets can be reduced by giving SectionKind an 'isSmallKind' bit (OR'd with 0x80). This provides a much clearer (and cached) predicate that ISel lowering can take advantage of when a small data load/store must be generated. The existing predicates in SectionKind may be modified to use the underlying Kind (AND-ing with 0x7f), so existing ISel behaviors are mostly unchanged.<br><br>The proposed target-independent small data classification has 2 usage avenues depending on the context:<br><br>For all GlobalObjects:<br><br>1. Pass GlobalObject to target-independent </font></div><div><font face="monospace, monospace">   TargetLoweringObjectFile::isGlobalInSmallSection. If it's a</font></div><div><font face="monospace, monospace">   declaration, </font><span style="font-family:monospace,monospace">make a virtual call to a new method named</span></div><div><font face="monospace, monospace">   TargetLoweringObjectFile::isGlobalInSmallSectionKind (doing </font></div><div><font face="monospace, monospace">   target-specific scrutiny) and return the result early.<br>2. Pass to TargetLoweringObjectFile::getKindForGlobal. </font></div><div><font face="monospace, monospace">   If the Kind is Data, BSS or Common, make a virtual call to</font></div><div><font face="monospace, monospace">   TargetLoweringObjectFile::isGlobalInSmallSectionKind just before </font></div><div><font face="monospace, monospace">   returning the SectionKind. If true is returned, set the 'isSmallKind' </font></div><div><font face="monospace, monospace">   bit in the returned SectionKind.<br>3. Return the result of the isSmallKind() predicate from </font></div><div><font face="monospace, monospace">   isGlobalInSmallSection<br><br>If the GlobalObject is known to be a definition, the process is even simpler:<br><br>1. Pass GlobalObject to TargetLoweringObjectFile::getKindForGlobal </font></div><div><font face="monospace, monospace">   (which calls isGlobalInSmallSectionKind in turn).<br>2. Act on isSmallKind() predicate (and conveniently get the </font></div><div><font face="monospace, monospace">   SectionKind at the same time).</font><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">I feel that the SectionKind modification is the best route, since it's already used to uniquely classify constant merge sections. Even though small data sections are linked in the same manner as their 'regular' counterparts, there must be a clear distinction when producing memory access code (and obviously selecting the target section to allocate in).</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">I'd like some input from PowerPC, MIPS, Hexagon and Lanai maintainers to ensure this approach accommodates their targets appropriately.</font></div></div></div>