This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix up creation of lowpart subregs in valtrack (PR debug/65678)
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Alexandre Oliva <aoliva at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sun, 26 Apr 2015 11:51:19 +0100
- Subject: Re: [PATCH] Fix up creation of lowpart subregs in valtrack (PR debug/65678)
- Authentication-results: sourceware.org; auth=none
- References: <20150407142311 dot GH19273 at tucnak dot redhat dot com>
Jakub Jelinek <jakub@redhat.com> writes:
> Hi!
>
> gen_rtx_SUBREG/gen_lowpart_SUBREG ICE when trying to create a subreg
> the backend doesn't like, lowpart_subreg returns NULL. But, for debug info
> purposes, all lowpart subregs are valid, a subreg in the debug insns or
> var-tracking notes is simply a mode punning construct, and even when the
> backend doesn't have any instruction to perform such operation, the debugger
> can always do the punning.
>
> var-tracking.c already has code to emit gen_rtx_raw_SUBREG if everything
> else fails, the following patch adjusts valtrack.c to do the same thing.
Looks like this has the potential to introduce nested subregs.
Also, the problem isn't just that the architecture can't do some accesses
easily (such as accessing the high part of a register). It's also that
GCC's model of subregs doesn't always give the right answer. E.g.
sometimes the endianess of a particular register is the opposite of what
GCC expects, or the value is modelled as occupying more than one register
but isn't evenly distributed through them.
I take your point about this being done in var-tracking.c, but it always
seemed dangerous there too...
Thanks,
Richard