On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > On 26 July 2016 at 17:07, Richard Biener <rguent...@suse.de> wrote: > > On Tue, 26 Jul 2016, Prathamesh Kulkarni wrote: > > > >> The following is an interesting case which broke stor-layout.c. > >> The patch warned for the following call to be dead from > >> bit_field_mode_iterator::next_mode() to get_mode_alignment (): > >> > >> /* Stop if the mode requires too much alignment. */ > >> if (GET_MODE_ALIGNMENT (m_mode) > m_align > >> && SLOW_UNALIGNED_ACCESS (m_mode, m_align)) > >> break; > >> > >> GET_MODE_ALIGNMENT (MODE) is just #defined as get_mode_alignment (MODE) > >> in machmode.h > >> > >> SLOW_UNALIGNED_ACCESS (MODE, ALIGN) is #defined to STRICT_ALIGNMENT > >> in defaults.h, and i386.h sets STRICT_ALIGNMENT to 0. > >> So essentially it comes down to: > >> > >> if (get_mode_alignment (m_mode) > m_align && 0) > >> break; > >> > >> which clearly makes get_mode_alignment(m_mode) a dead call > >> since it's a pure function. > >> However if a target overrides SLOW_UNALIGNED_ACCESS(mode, align) > >> and sets it to some runtime value, then the call won't be dead for that > >> target. > >> > >> Should we split the above in two different if conditions ? > >> if (GET_MODE_ALIGNMENT (m_mode) > m_align) > >> if (SLOW_UNALIGNED_ACCESS (m_mode, m_align)) > >> break; > > > > I'm surprised it's only one case that you hit ;) Be prepared for > > other targets to be broken similarly. > > > > This hints at the general issue of issueing warnings after optimization, > > they can easily become false positives. > Hmm, this would indeed give rise to such false positives :/ > I wonder whether we should restrict the warning only for cases when the call > is outermost expression ? > Not sure how to go about that. Maybe add a new flag to tree_exp for CALL_EXPR > say OUTERMOST_CALL_P, which is set by FE when the call is determined to be > outermost expression ?
That doesn't sound like a good idea. But I have no good idea either but to suggest this kind of warning is bad ;) Richard.
