On 5/15/19 6:09 AM, Richard Biener wrote: > On Wed, May 15, 2019 at 7:54 AM bin.cheng <bin.ch...@linux.alibaba.com> wrote: >> Hi, >> I noticed that cand_chain (first_interp/next_interp) is not maintained >> correctly >> in slsr_process_copy/slsr_process_cast (now slsr_process_copycast). This one >> fixes the issue, as well as records the "first" cand in stmt_cand_map. >> >> Hi Bill, is this correct or I misunderstood the code? Bootstrap and test on >> x86_64. > Looks good to me, still waiting for Bills feedback (now CCed).
Good catch, thanks for fixing! Okay for trunk. My mail server seems to have eaten the patch that introduces slsr_process_copycast. This is okay for trunk also, with one grammatical nit. Please change the comment before alloc_cand_and_fine_basis to read: "In case of a cast, the type is not propagated because it comes from the cast; nor is the base candidate's cast, which is no longer applicable." I'm very sorry for the delay due to vacation. Thanks! Bill > > Richard. > >> Thanks, >> bin >> >> 2019-05-15 Bin Cheng <bin.ch...@linux.alibaba.com> >> >> * gimple-ssa-strength-reduction.c (slsr_process_copycast): Record >> information about next_interp and the first cand.
