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

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

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 division will raise the same value, and therefore the cheapest option can be used.