Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

> On Thu, Dec 8, 2022 at 2:56 AM Jose E. Marchesi via Gcc-patches > wrote: >> >> The expand_expr_divmod function in expr.cc attempts to optimize cases >> where both arguments of a division/modulus are known to be positive >> when interpreted as signed. In these cases, both signed division and >

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

On Thu, Dec 8, 2022 at 2:56 AM Jose E. Marchesi via Gcc-patches wrote: > > The expand_expr_divmod function in expr.cc attempts to optimize cases > where both arguments of a division/modulus are known to be positive > when interpreted as signed. In these cases, both signed division and > unsigned

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

On 1/9/23 02:57, Jakub Jelinek via Gcc-patches wrote: On Mon, Jan 09, 2023 at 09:05:26AM +0100, Richard Biener wrote: On Wed, Jan 4, 2023 at 9:54 AM Jose E. Marchesi via Gcc-patches wrote: ping. Would this be a good approach for fixing the issue? adding the is_libcall bit enlarges rtx_d

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

On Mon, Jan 09, 2023 at 02:04:48PM +0100, Richard Biener via Gcc-patches wrote: > On Mon, Jan 9, 2023 at 10:58 AM Jakub Jelinek wrote: > > > > On Mon, Jan 09, 2023 at 09:05:26AM +0100, Richard Biener wrote: > > > On Wed, Jan 4, 2023 at 9:54 AM Jose E. Marchesi via Gcc-patches > > > wrote: > > > >

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

On Mon, Jan 9, 2023 at 10:58 AM Jakub Jelinek wrote: > > On Mon, Jan 09, 2023 at 09:05:26AM +0100, Richard Biener wrote: > > On Wed, Jan 4, 2023 at 9:54 AM Jose E. Marchesi via Gcc-patches > > wrote: > > > > > > > > > ping. > > > Would this be a good approach for fixing the issue? > > > > adding

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

On Mon, Jan 09, 2023 at 09:05:26AM +0100, Richard Biener wrote: > On Wed, Jan 4, 2023 at 9:54 AM Jose E. Marchesi via Gcc-patches > wrote: > > > > > > ping. > > Would this be a good approach for fixing the issue? > > adding the is_libcall bit enlarges rtx_def by 8 bytes - there's no room for > m

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

On Wed, Jan 4, 2023 at 9:54 AM Jose E. Marchesi via Gcc-patches wrote: > > > ping. > Would this be a good approach for fixing the issue? adding the is_libcall bit enlarges rtx_def by 8 bytes - there's no room for more bits here. I really wonder how other targets avoid the issue you are pointing

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

ping. Would this be a good approach for fixing the issue? > Hi Jakub. > >> On Thu, Dec 08, 2022 at 02:02:36PM +0100, Jose E. Marchesi wrote: >>> So, I guess the right fix would be to call assemble_external_libcall >>> during final? The `.global FOO' directive would be generated >>> immediately

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

Hi Jakub. > On Thu, Dec 08, 2022 at 02:02:36PM +0100, Jose E. Marchesi wrote: >> So, I guess the right fix would be to call assemble_external_libcall >> during final? The `.global FOO' directive would be generated >> immediately before the call sequence, but I guess that would be ok. > > During

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

>> Am 08.12.2022 um 11:56 schrieb Jose E. Marchesi via Gcc-patches >> : >> >> The expand_expr_divmod function in expr.cc attempts to optimize cases >> where both arguments of a division/modulus are known to be positive >> when interpreted as signed. In these cases, both signed division and >>

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

> Am 08.12.2022 um 11:56 schrieb Jose E. Marchesi via Gcc-patches > : > > The expand_expr_divmod function in expr.cc attempts to optimize cases > where both arguments of a division/modulus are known to be positive > when interpreted as signed. In these cases, both signed division and > unsig

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

On Thu, Dec 08, 2022 at 02:02:36PM +0100, Jose E. Marchesi wrote: > So, I guess the right fix would be to call assemble_external_libcall > during final? The `.global FOO' directive would be generated > immediately before the call sequence, but I guess that would be ok. During final only if all th

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

Hi Jakub. > On Thu, Dec 08, 2022 at 11:59:44AM +0100, Jose E. Marchesi via Gcc-patches > wrote: >> gcc/ChangeLog >> >> * expr.cc (expand_expr_divmod): Avoid side-effects of trying >> sequences involving funcalls in optimization. > > That looks wrong. > The globals for mentioned calls

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

On Thu, Dec 08, 2022 at 11:59:44AM +0100, Jose E. Marchesi via Gcc-patches wrote: > gcc/ChangeLog > > * expr.cc (expand_expr_divmod): Avoid side-effects of trying > sequences involving funcalls in optimization. That looks wrong. The globals for mentioned calls just shouldn't be emitt