Bug 39368 - loc_descriptor doesn't call delegitimize_address on MEMs
Summary: loc_descriptor doesn't call delegitimize_address on MEMs
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Jorn Wolfgang Rennecke
URL:
Keywords: patch
Depends on:
Blocks: 39363
  Show dependency treegraph
 
Reported: 2009-03-04 20:58 UTC by Jorn Wolfgang Rennecke
Modified: 2010-05-26 07:03 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-03-05 02:30:29


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jorn Wolfgang Rennecke 2009-03-04 20:58:19 UTC
For a RISC target that doesn't allow memory-indirect addressing, the
proper way to represent an access of a symbol found in the GOT is to
first load the symbol from the GOT into a register, and then use
that register for memory access or call as needed.

For proper scheduling and instruction selection, the symbol load
source should be represented as what it is, i.e. a MEM.
So we have a (MEM (unspec ... UNSPEC_GOT)) .
For the purposes of debug output, this should be translated back into
the symbol_ref it represents.

However, loc_descriptor looks only into the address inside a MEM,
it does not process the entire mem with targetm.delegitimize_address.
I.e. there is no way to get rid of the MEM if it is not nested in
another MEM.
Comment 1 Jorn Wolfgang Rennecke 2009-03-05 02:30:29 UTC
patch is here:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00267.html
Comment 2 Jakub Jelinek 2010-05-26 07:03:10 UTC
Not sure whether this patch is still needed now that var-tracking already delegitimizes MEMs (and their addresses) too.
That said, if you have a testcase where this is still needed, the patch looks reasonable, so you might want to ping it.