This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Combine location with block using block_locations
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Dehao Chen <dehao at google dot com>, Diego Novillo <dnovillo at google dot com>, Dodji Seketeli <dodji at redhat dot com>, gcc-patches at gcc dot gnu dot org, Jakub Jelinek <jakub at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>, David Li <davidxl at google dot com>, Tom Tromey <tromey at redhat dot com>, Jason Merrill <jason at redhat dot com>, Richard Henderson <rth at redhat dot com>
- Date: Wed, 12 Sep 2012 11:08:14 +0200
- Subject: Re: [PATCH] Combine location with block using block_locations
- References: <CAO2gOZXFkCpuFqXpPw6ju14BB=RBdt-kDhKsJgk4N41=Q19VHw@mail.gmail.com> <m3y5lhnbzi.fsf@redhat.com> <CAO2gOZVFTNraCNOS4J1dV9T7XyFY=QHbhZ_i3Jx9yY6EM5+46w@mail.gmail.com> <CAO2gOZWsX_SP+zZX5t_xnXUUVSCz0WpRQy=oJumKY3_mDCXGSA@mail.gmail.com> <CAFiYyc0X7kGj95SvQfBpDxY=UMvyDXCCALwFTXXn+4oYJ8x04g@mail.gmail.com> <CAO2gOZWG_Gw3MejvA58M1GrXj=7s6fkURX3NmGT=cUgMwHz=RQ@mail.gmail.com> <CAFiYyc0c3ZyLkbTGiiOOi0sCC0Ju9=PQLZ-BAOV2RFYVttzvCA@mail.gmail.com> <5049D5AD.5010405@google.com> <504A2EE0.8020704@google.com> <CAO2gOZWX+A3R0MGvWXYztBokQ=ezHNiS3vR0Cu9cbGPi_102ww@mail.gmail.com> <CAFiYyc0wGqgPR6Sqk2sOCg+LnhfFmk8dChb54oh=EjiTFzftyw@mail.gmail.com> <CAO2gOZVNK5uS7NJt1uV6S7nCMtoj+g23BJiH_=P6TLgkh4d1Sw@mail.gmail.com> <CAFiYyc1pA9+=_OE50rCSmKG4ftasrNYE8jRMt3gf_F+6ee9OVw@mail.gmail.com> <alpine.LNX.2.00.1209111500200.9940@wotan.suse.de> <CAFiYyc0vM+LZJ_6MRFud9c1LhyFsu2jf-E38FuDryoMo5G7iYw@mail.gmail.com> <CAO2gOZV8SP-sOVEJBEsvF+M3yiKwtw7yWarfhZ1xeCVYjE_7KA@mail.gmail.com> <alpine.LNX.2.00.1209111728160.9940@wotan.suse.de>
On Tue, Sep 11, 2012 at 5:32 PM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 11 Sep 2012, Dehao Chen wrote:
>
>> Looks like we have two choices:
>>
>> 1. Stream out block info, and use LTO_SET_PREVAIL for TREE_CHAIN(t)
>
> This will actually not work correctly in some cases. The problem is, if
> the prevailing decl is already part of another chain (say in another
> block_var list) you would break the current chain. Hence block vars need
> special handling in the lto streamer (another reason why tree_chain is not
> the most clever think to use for this chain). This problem area needs to
> be solved somehow if block info is to be preserved correctly.
Well. The issue is that at present we stream BLOCKs in the function section
via its DECL_INTIAL. Which means we _never_ should get a non-prevailing
DECL in BLOCK_VARS. You need to debug why that doesn't work anymore.
Possibly the BLOCK leaks into decls it should not leak to via the location
mechanism?
>> 2. Don't stream out block info for LTO, and still call LTO_NO_PREVAIL
>> (TREE_CHAIN (t)).
>
> That's also a large hammer as it basically will mean no debug info after
> LTO :-/ Sigh, at this point I have no good solution that doesn't involve
> quite some work, perhaps your hack is good enough for the time being,
> though I hate it :)
It hides a bug. If we replace anything in BLOCK_VARS then the risk is
that you generate an infinite chain in some BLOCK_VARS list and thus
get infinite loops somewhere in the compiler.
So, no, that's not an option.
Richard.
>
> Ciao,
> Michael.