This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to avoid literal pools ?

Note: This was originally posted on 19th January 2012 at http://forums.arm.com

Hello everyone,

I am using Cortex-R4F (TI TMS570), and I noticed that ARM C compiler often adds data in literal pools as in example below :
C code :
RTI_Re_TickFlag = 0;

ASM generated code :
000004 4c66              LDR      r4,|L1.416|
000006 2700              MOVS     r7,#0
...
    ENDP
    |L1.416|
         DCD      RTI_Re_TickFlag

My problem is that this constant is in the same section than the code, so the Cortex-R4 Harward architecture (separate data/instruction) is not used at its best.
It makes load/store unit (LSU) accesses interfere with prefetch unit (PFU) accesses.

So, can we make armcc (with optimization options or some directives...) not generate literal pools ?

Thanks

Best regards

Christophe

Parents

Martin Weidmann over 12 years ago

Note: This was originally posted on 20th January 2012 at http://forums.arm.com

I'm not sure I agree with your reasoning...

If the section is in cacheable memory, then the fetch would come from the I cache and the load from the D cache. These shouldn't interfere with each other (unless you get to cache misses at once, in which case you'd have contention for the bus interface). If its in BTCM, it can* support two accesses per cycle, so probably no interference there. You would potentially have interference if the section is in ATCM, as that supports only a single access per cycle.

* It's a synthesis choice how to set up the BTCM, no idea how your TI part does it.

That said, I can see why you might want to avoid polluting your D cache with the odd literal stored in memory which is mostly instruction.
Cancel
Vote up 0 Vote down

Cancel

Reply

Martin Weidmann over 12 years ago

Note: This was originally posted on 20th January 2012 at http://forums.arm.com

I'm not sure I agree with your reasoning...

If the section is in cacheable memory, then the fetch would come from the I cache and the load from the D cache. These shouldn't interfere with each other (unless you get to cache misses at once, in which case you'd have contention for the bus interface). If its in BTCM, it can* support two accesses per cycle, so probably no interference there. You would potentially have interference if the section is in ATCM, as that supports only a single access per cycle.

* It's a synthesis choice how to set up the BTCM, no idea how your TI part does it.

That said, I can see why you might want to avoid polluting your D cache with the odd literal stored in memory which is mostly instruction.
Cancel
Vote up 0 Vote down

Cancel

Children

No data