On Mon, Aug 26, 2024 at 2:43 PM Haochen Jiang wrote:
>
> Hi all,
>
> I have just commited AVX10.2 new instructions patches into trunk hours
> ago. The next and final part for AVX10.2 upstream is to optimize code
> with AVX10.2 new instructions.
>
> In this patch series, it will contain the followi
From: Pan Li
This patch would like to add strict check for imm operand of .SAT_SUB
matching. We have no type checking for imm operand in previous, which
may result in unexpected IL to be catched by .SAT_SUB pattern.
We leverage the int_fits_type_p here to make sure the imm operand is
a int type
From: Pan Li
This patch would like to add strict check for imm operand of .SAT_SUB
matching. We have no type checking for imm operand in previous, which
may result in unexpected IL to be catched by .SAT_SUB pattern.
We leverage the int_fits_type_p here to make sure the imm operand is
a int type
Hi Martin,
On Sun, Sep 01, 2024 at 11:51:10AM GMT, Martin Uecker wrote:
>
> Alex,
>
> I am all for making things more consistent, but there is also a cost
> to changing stuff too much. length is the established
> term in most programming languages and I would recommend to stick
> to it.
>
>
On Sun 2024-09-01 09:25:07, Jeff Law wrote:
>
>
> On 9/1/24 9:19 AM, Filip Kastl wrote:
> > (I'm Cc-ing Diego since he originally contributed the VRP pass and Jeff
> > because
> > I've seen him in git blame on many lines of vr-values.cc around the place I
> > would like to make modifications)
>
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: Monday, August 26, 2024 4:21 PM
> To: Thomas Schwinge ; gcc-patches@gcc.gnu.org
> Subject: [nvptx] Fix code-gen for alias attribute
>
> External email: Use caution opening links or attachments
>
>
> Hi,
> For the following test (a
On Sun, Sep 1, 2024 at 4:27 PM Kugan Vivekanandarajah
wrote:
>
> Hi Andrew.
>
> > On 28 Aug 2024, at 2:23 pm, Andrew Pinski wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, Aug 27, 2024 at 8:54 PM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi Richard,
On 9/1/24 8:50 PM, Li, Pan2 wrote:
Thanks Jeff for comments.
OK. Presumably the code you're getting here is more efficient than
whatever standard expansion would provide? If so, should we be looking
at moving some of this stuff into generic expanders? I don't really see
anything all that
On 9/1/24 9:19 AM, Filip Kastl wrote:
(I'm Cc-ing Diego since he originally contributed the VRP pass and Jeff because
I've seen him in git blame on many lines of vr-values.cc around the place I
would like to make modifications)
Hello,
In this RFC I'd like to propose the following: When the v
On Tue, Aug 27, 2024 at 1:11 PM H.J. Lu wrote:
>
> Update analyze_parms not to disable function parameter analysis for
> -ffat-lto-objects. Tested on x86-64, there are no differences in zstd
> with "-O2 -flto=auto" -g "vs -O2 -flto=auto -g -ffat-lto-objects".
>
> PR ipa/116410
> *
On 8/29/24 12:25 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to support the scalar signed ssadd pattern
for the RISC-V backend. Aka
Form 1:
#define DEF_SAT_S_ADD_FMT_1(T, UT, MIN, MAX) \
T __attribute__((noinline)) \
sat_s_add_##T##_fmt_1 (T x,
On 8/29/24 9:04 PM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to add test cases for the unsigned vector .SAT_ADD
when one of the operand is IMM.
Form 3:
#define DEF_VEC_SAT_U_ADD_IMM_FMT_3(T, IMM) \
T __attribute__((noinline))
Hi Jens, Martin,
On Wed, Aug 14, 2024 at 05:44:57PM GMT, Jens Gustedt wrote:
> Am 14. August 2024 16:47:32 MESZ schrieb Alejandro Colomar :
> > > > I was thinking of renaming the proposal to elementsof(), to avoid
> > > > confusion between length of an array and length of a string. Would you
> >
Thanks Jeff.
> But I would expect that may be beneficial on other targets as well.
I think x86 have the similar insn for saturation, for example as paddsw in
below link.
https://www.felixcloutier.com/x86/paddsb:paddsw
And the backend of x86 implemented some of them already I bet, like usadd,
us
Alex,
I am all for making things more consistent, but there is also a cost
to changing stuff too much. length is the established
term in most programming languages and I would recommend to stick
to it.
Note that it is not true that the standard consistently refers to
char a[3][n]
as a VLA
(I'm Cc-ing Diego since he originally contributed the VRP pass and Jeff because
I've seen him in git blame on many lines of vr-values.cc around the place I
would like to make modifications)
Hello,
In this RFC I'd like to propose the following: When the value range statement
simplification machine
On 8/29/24 2:12 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to add test cases for the unsigned scalar quad and
oct .SAT_TRUNC form 2. Aka:
Form 2:
#define DEF_SAT_U_TRUC_FMT_2(NT, WT) \
NT __attribute__((noinline)) \
sat_u_truc_##WT##_to_##NT##_
Thanks Jeff for comments.
> OK. Presumably the code you're getting here is more efficient than
> whatever standard expansion would provide? If so, should we be looking
> at moving some of this stuff into generic expanders? I don't really see
> anything all that target specific here.
Mostly
Hi Andrew.
> On 28 Aug 2024, at 2:23 pm, Andrew Pinski wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Tue, Aug 27, 2024 at 8:54 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>> Thanks for the reply.
>>
>>> On 27 Aug 2024, at 7:05 pm, Richard Biener
On 8/30/24 1:23 AM, pan2...@intel.com wrote:
From: Pan Li
In previous, we have some specially handling for both the .SAT_ADD and
.SAT_SUB for unsigned int. There are similar to take care of SImode
in RV64 for zero extend. Thus refactor these two helper function
into one for possible code d
Hi Jason,
On 26 Aug 2024, at 19:23, Jason Merrill wrote:
> On 8/25/24 12:37 PM, Simon Martin wrote:
>> On 24 Aug 2024, at 23:59, Simon Martin wrote:
>>> On 24 Aug 2024, at 15:13, Jason Merrill wrote:
>>>
On 8/23/24 12:44 PM, Simon Martin wrote:
> We currently emit an incorrect -Woverload
On 9/1/24 9:47 AM, Filip Kastl wrote:
On Sun 2024-09-01 09:25:07, Jeff Law wrote:
On 9/1/24 9:19 AM, Filip Kastl wrote:
(I'm Cc-ing Diego since he originally contributed the VRP pass and Jeff because
I've seen him in git blame on many lines of vr-values.cc around the place I
would like to
This came up in discussion of an earlier patch.
I'm in two minds as to whether it's a good idea or not - the underlying
issue being that libubsan does not yet (AFAICT) have the concept of a
coroutine, so that the diagnostics are not very specific and might appear
strange (i.e. "execution reached t
This is a small bug in the ext-dce code's handling of promoted subregs.
Essentially when we see a promoted subreg we need to make additional bit
groups live as various parts of the RTL path know that an extension of a
suitably promoted subreg can be trivially eliminated.
When I added support
On 8/27/24 3:17 AM, Xianmiao Qu wrote:
Currently, in RV32, even with the D extension enabled, the cost of DFmode
register moves is still set to 'COSTS_N_INSNS (2)'. This results in the
'lower-subreg' pass splitting DFmode register moves into two SImode SUBREG
register moves, leading to the gen
25 matches
Mail list logo
