let me explain more about the test [4,4]. As I understand, the self test will
run more than 1 time for VNx4BI.
The first time, precision[VNx4BI] = [8, 8], then the PR precision part will
adjust it to [4, 4].
The rest times, precision[VNx4BI] = [4, 4], then can_* will return false and
hit the
Actually, we just want to differentiate VNx1BI VNx2BI VNx4BI VNx8BI, and they
are considered the same in GCC which produce BUG in RVV currently.
This patch is just adjust precision to differentiate them but may not be (like
you say), they may not be handled accurately according precision.
On 01/03/2023 10:52, Andre Vieira (lists) wrote:
On 01/03/2023 10:01, Andrew Stubbs wrote:
> On 28/02/2023 23:01, Kwok Cheung Yeung wrote:
>> Hello
>>
>> This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
>> target hook for the AMD GCN architecture, such that when
盼 李 via Gcc-patches writes:
> Just have a test with the below code, the [0x4, 0x4] test comes from VNx4BI.
> You can notice that the mode size is unchanged.
>
> printf ("can_div_away_from_zero_p (mode_precision[E_%smode], "
> "BITS_PER_UNIT, _size[E_%smode]);\n", m->name, m->name);
>
>
Just have a test with the below code, the [0x4, 0x4] test comes from VNx4BI.
You can notice that the mode size is unchanged.
printf ("can_div_away_from_zero_p (mode_precision[E_%smode], "
"BITS_PER_UNIT, _size[E_%smode]);\n", m->name, m->name);
VNx4BI Before precision [0x4, 0x4], size
Currently, if the gcc toolchain is relocated and installed from shared state
cache, then you try and compile
preprocessed source (.i or .ii files), the compiler will try and access the
builtin sysroot location
rather than the --sysroot option specified on the commandline. If access to
that
On Tue, 28 Feb 2023, Richard Sandiford wrote:
> Tamar Christina writes:
> >> -Original Message-
> >> From: Richard Sandiford
> >> Sent: Tuesday, February 28, 2023 11:09 AM
> >> To: Tamar Christina
> >> Cc: Tamar Christina via Gcc-patches ; nd
> >> ; rguent...@suse.de;
Thank you for the explanation.
For [4,4] I need extra time to figure out which one, but I confirmed it occurs
from the log.
This PR precision adjustment part tries to align the ISA as juzhe mentioned, by
the underlying precision adjustment part.
VNx64BI precision [0x40, 0x40] // unchanged
盼 李 via Gcc-patches writes:
> Thank you all for your quick response.
>
> As juzhe mentioned, the memory access of RISC-V will be always aligned to the
> bytes boundary with the compact mode, aka ceil(vl / 8) bytes for vbool*.
OK, thanks to both of you. This is what I'd have expected.
In that
Thank you all for your quick response.
As juzhe mentioned, the memory access of RISC-V will be always aligned to the
bytes boundary with the compact mode, aka ceil(vl / 8) bytes for vbool*.
Actually, the data [4,4] comes from the self-test, the RISC-V precision mode as
below.
VNx64BI
On 01/03/2023 10:01, Andrew Stubbs wrote:
> On 28/02/2023 23:01, Kwok Cheung Yeung wrote:
>> Hello
>>
>> This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
>> target hook for the AMD GCN architecture, such that when vectorized,
>> calls to builtin standard math functions
>> Is it right that, for RVV, a load or store of [4,4] will access [8,8]
>>bits, even when that means accessing fully-unused bytes? E.g. 4+4X
>>when X=3 would be 16 bits/2 bytes of useful data, but a bitsize of
>>8+8X would be 32 bits/4 bytes. So a store of [8,8] for a precision
>>of [4,4] would
Similar to my num_pairs comment. If we're fixing missed optimizations,
then yes. Otherwise I'd prefer to remove it soon.
That being said, you are the release manager and if you feel strongly
about this I would defer to you.
Aldy
On 2/28/23 14:47, Richard Biener via Gcc-patches wrote:
I would prefer not touching this as it was intended, and about to be
removed. However, if we have actual regressions or missed optimizations
because of the current behavior I could be convinced otherwise.
Aldy
On 2/28/23 14:47, Richard Biener via Gcc-patches wrote:
irange::num_pairs has odd
On 2/28/23 14:47, Richard Biener via Gcc-patches wrote:
simplify_using_ranges::two_valued_val_range_p has odd code to
verify that an anti-range is two-valued which relies on
num_pairs () returning two for anti-ranges despite there's only
one pair and relying on lower/upper_bound treating that
On 3/1/23 11:12, Richard Biener wrote:
On Wed, 1 Mar 2023, Aldy Hernandez wrote:
On 2/28/23 10:41, Richard Biener wrote:
On Mon, 27 Feb 2023, Aldy Hernandez wrote:
On 2/27/23 14:58, Richard Biener wrote:
After fixing PR107561 the following avoids looking at VR_ANTI_RANGE
ranges
Hi!
I'd like to ping a few pending patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
- PR107846 - P1 - c-family: Account for integral promotions of left shifts
for -Wshift-overflow warning
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610285.html
-
On Wed, 1 Mar 2023, Aldy Hernandez wrote:
>
>
> On 2/28/23 10:41, Richard Biener wrote:
> > On Mon, 27 Feb 2023, Aldy Hernandez wrote:
> >
> >>
> >>
> >> On 2/27/23 14:58, Richard Biener wrote:
> >>> After fixing PR107561 the following avoids looking at VR_ANTI_RANGE
> >>> ranges where it
"Li, Pan2" writes:
> Hi Richard Sandiford,
>
> Just tried the overloaded constant divisors with below print div, it works as
> you mentioned, !
>
> printf ("can_div_away_from_zero_p (mode_precision[E_%smode], "
> "BITS_PER_UNIT, _size[E_%smode]);\n", m->name, m->name);
>
> template
>
OK.
Thanks.
On Tue, Feb 28, 2023 at 2:48 PM Richard Biener via Gcc-patches
wrote:
>
> The following avoids the need to special-case storage requirement
> and copying for irange_storage_slot by making sure we canonicalize
> such ranges to int_range<2>.
>
> * tree-ssanames.cc
Ughh, you're touching everything I'm nuking next release ;-).
But yes, that's an oversight.
OK.
On Tue, Feb 28, 2023 at 2:48 PM Richard Biener via Gcc-patches
wrote:
>
> when vrange_printer::visit gets a VR_ANTI_RANGE it should print it
> as such, not just print the first element as range.
On 28/02/2023 23:01, Kwok Cheung Yeung wrote:
Hello
This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
target hook for the AMD GCN architecture, such that when vectorized,
calls to builtin standard math functions such as asinf, exp, pow etc.
are converted to calls to the
On 2/28/23 10:41, Richard Biener wrote:
On Mon, 27 Feb 2023, Aldy Hernandez wrote:
On 2/27/23 14:58, Richard Biener wrote:
After fixing PR107561 the following avoids looking at VR_ANTI_RANGE
ranges where it doesn't seem obvious the code does the correct
thing here (lower_bound and
Hi!
On Tue, Feb 28, 2023 at 10:59:03PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Feb 28, 2023 at 07:19:40PM +, Qing Zhao wrote:
> > Understood.
> > So, your patch fixed this bug, and then [0] arrays are instrumented by
> > default with this patch.
> >
> > > Well, it would
Hi,
Please CC fortran@gcc for Fortran patches.
Fortraners: Please see my add-on suggestion/.diff for 'do_simply' below and
the original email at
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613019.html
On 01.03.23 08:09, HAO CHEN GUI via Gcc-patches wrote:
The patch escalates the
On Wed, Mar 1, 2023 at 9:52 AM NightStrike via Gcc-patches
wrote:
>
> On Thu, Feb 16, 2023, 11:10 LIU Hao via Gcc-patches
> wrote:
>
> >
> > --
> > Best regards,
> > LIU Hao
> >
>
> Ping
OK.
> >
On Tue, Feb 28, 2023 at 11:04:42AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Feb 28, 2023 at 12:51:06AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > And then there is a question whether we want to emit rtti for
> > _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16)
On Wed, 1 Mar 2023, Jakub Jelinek wrote:
> Hi!
>
> When these tree codes were introduced, expand_debug_expr hasn't been
> updated to handle them. For the VEC_*_EXPR we currently mostly punt, the
> non-vector ones can be handled easily. In release compilers this doesn't
> ICE, but with checking
Hi!
When these tree codes were introduced, expand_debug_expr hasn't been
updated to handle them. For the VEC_*_EXPR we currently mostly punt, the
non-vector ones can be handled easily. In release compilers this doesn't
ICE, but with checking we ICE so that we make sure to handle all the needed
The function slpeel_can_duplicate_loop_p fails to verify we can
copy blocks, instead slpeel_tree_duplicate_loop_to_edge_cfg does
but that's too late. The following fixes this, also simplifying
error reporting which is somewhat pointless if we ICE immediately.
Bootstrapped and tested on
Hi Richard, hi all,
On 01.03.23 09:18, Richard Biener via Gcc-patches wrote:
I thought we were moving towards using the simd attribute instead and
moving away from these kind of patches.
Though since gcn is a special target that including math.h normally
does not happen for offloading this
On Thu, Feb 16, 2023, 11:10 LIU Hao via Gcc-patches
wrote:
>
> --
> Best regards,
> LIU Hao
>
Ping
>
On Wed, Mar 1, 2023 at 12:07 AM Andrew Pinski via Gcc-patches
wrote:
>
> On Tue, Feb 28, 2023 at 3:02 PM Kwok Cheung Yeung
> wrote:
> >
> > Hello
> >
> > This patch implements the TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
> > target hook for the AMD GCN architecture, such that when
101 - 133 of 133 matches
Mail list logo
