> OK if that pre-commit CI works out.
The CI didn't pick it up, guess it needs to be a bit more explicit.
In the meanwhile, however, I managed to catch a short window with
> 10G free on gcc185 => Bootstrap and regtest successful on aarch64.
Going to push the patch later today.
Regards
Robin
On Mon, May 13, 2024 at 4:14 PM Robin Dapp wrote:
>
> > What happens if we simply remove all of the force_reg here?
>
> On x86 I bootstrapped and tested the attached without fallout
> (gcc188, so it's no avx512-native machine and therefore limited
> coverage). riscv regtest is unchanged.
> For
> What happens if we simply remove all of the force_reg here?
On x86 I bootstrapped and tested the attached without fallout
(gcc188, so it's no avx512-native machine and therefore limited
coverage). riscv regtest is unchanged.
For aarch64 I would to rely on the pre-commit CI to pick it
up (does
On Mon, May 13, 2024 at 8:18 AM Robin Dapp wrote:
>
> > How does this make a difference in the end? I'd expect say forwprop to
> > fix things?
>
> In general we try to only add the masking "boilerplate" of our
> instructions at split time so fwprop, combine et al. can do their
> work uninhibited
> How does this make a difference in the end? I'd expect say forwprop to
> fix things?
In general we try to only add the masking "boilerplate" of our
instructions at split time so fwprop, combine et al. can do their
work uninhibited of it (and we don't need numerous
(if_then_else ...
On Fri, May 10, 2024 at 3:18 PM Robin Dapp wrote:
>
> Hi,
>
> this only forces the first comparison operator into a register if it is
> not already suitable.
>
> Bootstrap and regtest is running on x86 and aarch64, successful on p10.
> Regtested on riscv.
How does this make a difference in the
Hi,
this only forces the first comparison operator into a register if it is
not already suitable.
Bootstrap and regtest is running on x86 and aarch64, successful on p10.
Regtested on riscv.
gcc/ChangeLog:
PR middle-end/113474
* internal-fn.cc (expand_vec_cond_mask_optab_fn):
