On 10/24/23 13:36, rep.dot@gmail.com wrote:
As said, I don't see why the below was not cleaned up before the V1 submission.
Iff it breaks when manually CSEing, I'm curious why?
The function below looks identical in v12 of the patch.
Why didn't you use common subexpressions?
ba
Using CSE her
On Tue, Oct 24, 2023 at 04:46:02PM -0400, Jason Merrill wrote:
> On 10/24/23 12:18, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > Here we issue a bogus error: invalid operands of types 'unsigned char:2'
> > and 'int' to binary 'operator!
On 2023-10-24 16:30, Qing Zhao wrote:
Situation 2: With O0, the routine “get_size_from” was NOT inlined into “foo”,
therefore, the call to __bdos is Not in the same routine as the instantiation
of the object, As a result, the TYPE info and the attached counted_by info of
the object can NOT be
On 2023-10-24 16:38, Martin Uecker wrote:
Here is another proposal: Add a new builtin function
__builtin_with_size(x, size)
that return x but behaves similar to an allocation
function in that BDOS can look at the size argument
to discover the size.
The FE insers this function when the field i
On 10/24/23 13:03, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
like the right approach?
-- >8 --
This PR is another instance of NON_DEPENDENT_EXPR having acted as an
"analysis barrier" for middle-end routines, and now that it's gone we
may end up passi
On 10/23/23 19:51, Patrick Palka wrote:
The second patch in this series is new and ensures that the candidates
list isn't mysteriously missing some candidates when noting other
candidates due to deletedness.
-- >8 --
This patch:
* changes splice_viable to move the non-viable candidates to t
Hi,
Sorry the slow review. I clearly didn't think this through properly
when doing the review of the original patch, so I wanted to spend
some time working on the code to get a better understanding of
the problem.
Prathamesh Kulkarni writes:
> Hi,
> For the following test-case:
>
> typedef floa
Robin Dapp writes:
> The attached patch introduces a VCOND_MASK_LEN, helps for the riscv cases
> that were broken before and looks unchanged on x86, aarch64 and power
> bootstrap and testsuites.
>
> I only went with the minimal number of new match.pd patterns and did not
> try stripping the length
On 10/23/23 19:51, Patrick Palka wrote:
During overload resolution, we sometimes outright ignore a function from
the overload set and leave no trace of it in the candidates list, for
example when we find a perfect non-template candidate we discard all
function templates, or when the callee is a t
On 10/23/23 19:51, Patrick Palka wrote:
With the previous two patches in place, we can now extend our
deletedness diagnostic to note the other considered candidates, e.g.:
deleted16.C: In function 'int main()':
deleted16.C:10:4: error: use of deleted function 'void f(int)'
10 | f(0
> On Oct 24, 2023, at 5:03 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-24 16:30, Qing Zhao wrote:
>> Situation 2: With O0, the routine “get_size_from” was NOT inlined into
>> “foo”, therefore, the call to __bdos is Not in the same routine as the
>> instantiation of the object, As a result, t
> On Oct 24, 2023, at 4:38 PM, Martin Uecker wrote:
>
> Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
>> Hi, Sid,
>>
>> Really appreciate for your example and detailed explanation. Very helpful.
>> I think that this example is an excellent example to show (almost) all the
>> i
On 2023-10-24 18:41, Qing Zhao wrote:
On Oct 24, 2023, at 5:03 PM, Siddhesh Poyarekar wrote:
On 2023-10-24 16:30, Qing Zhao wrote:
Situation 2: With O0, the routine “get_size_from” was NOT inlined into “foo”,
therefore, the call to __bdos is Not in the same routine as the instantiation
of
On 2023-10-24 18:51, Qing Zhao wrote:
Thanks for the proposal!
So what you suggested is:
For every x.buf, change it as a __builtin_with_size(x.buf, x.L) in the FE,
then the call to the _bdos (x.buf, 1) will
Become:
_bdos(__builtin_with_size(x.buf, x.L), 1)?
Then the implicit use of x.L
Hi,
Trunk gcc supports more constants to be built via two instructions: e.g.
"li/lis; xori/xoris/rldicl/rldicr/rldic".
And then num_insns_constant should also be updated.
Bootstrap & regtest pass ppc64{,le}.
Is this ok for trunk?
BR,
Jeff (Jiufu Guo)
gcc/ChangeLog:
* config/rs6000/rs60
Hi,
For constants with 16bit values, 'li or lis' can be used to generate
the value. For 34bit constant, 'pli' is ok to generate the value.
Bootstrap®test pass on ppc64{,le}.
Is this ok for trunk?
BR,
Jeff (Jiufu Guo)
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_emit_set_long_const
Hi,
Sometimes, a complicated constant is built via 3(or more)
instructions to build. Generally speaking, it would not be
as faster as loading it from the constant pool (as a few
discussions in PR63281).
For the concern that I raised in:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599676
Hi,
on 2023/10/25 10:00, Jiufu Guo wrote:
> Hi,
>
> Trunk gcc supports more constants to be built via two instructions: e.g.
> "li/lis; xori/xoris/rldicl/rldicr/rldic".
> And then num_insns_constant should also be updated.
>
Thanks for updating this.
> Bootstrap & regtest pass ppc64{,le}.
> Is
on 2023/10/25 10:00, Jiufu Guo wrote:
> Hi,
>
> For constants with 16bit values, 'li or lis' can be used to generate
> the value. For 34bit constant, 'pli' is ok to generate the value.
>
> Bootstrap®test pass on ppc64{,le}.
> Is this ok for trunk?
>
> BR,
> Jeff (Jiufu Guo)
>
> gcc/ChangeLog:
Hi,
on 2023/10/25 10:00, Jiufu Guo wrote:
> Hi,
>
> Sometimes, a complicated constant is built via 3(or more)
> instructions to build. Generally speaking, it would not be
> as faster as loading it from the constant pool (as a few
> discussions in PR63281).
I may miss some previous discussions, b
Hi,
This is almost a repost for v2 which was posted at[1] in March
excepting for:
1) rebased from r14-4810 which is relatively up-to-date,
some conflicts on "int to bool" return type change have
been resolved;
2) adjust commit log a bit;
3) fix misspelled "articial" with "artificia
Hi,
Gentle ping this series:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607146.html
BR,
Kewen
on 2022/11/24 17:15, Kewen Lin wrote:
> Hi,
>
> Following Segher's suggestion, this patch series is to rework
> function rs6000_emit_vector_compare for vector float an
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609993.html
BR,
Kewen
>> on 2023/1/16 17:08, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> As Honza pointed out in [1], the current uses of function
>>> optimize_function_for_speed_p in rs6000_option_override_intern
This adds a match pattern for `a != C1 ? abs(a) : C2` which gets simplified
to `abs(a)`. if C1 was originally *_MIN then change it over to use absu instead
of abs.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/111957
gcc/ChangeLog:
* match
I noticed we were missing optimizing `a / (1 << b)` when
we know that a is nonnegative but only due to ranger information.
This adds the use of the global ranger to tree_single_nonnegative_warnv_p
for SSA_NAME.
I didn't extend tree_single_nonnegative_warnv_p to use the ranger for floating
point nor
RV64 comapre and branch instructions only support 64-bit operands.
The backend unconditionally generates zero/sign extend at Expand time
for compare and branch operands even if they are already as such
e.g. function args which ABI guarantees to be sign-extended (at callsite).
And subsequently REE
Am Dienstag, dem 24.10.2023 um 22:51 + schrieb Qing Zhao:
>
> > On Oct 24, 2023, at 4:38 PM, Martin Uecker wrote:
> >
> > Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
> > > Hi, Sid,
> > >
> > > Really appreciate for your example and detailed explanation. Very helpful.
> > >
> Am 24.10.2023 um 22:38 schrieb Martin Uecker :
>
> Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
>> Hi, Sid,
>>
>> Really appreciate for your example and detailed explanation. Very helpful.
>> I think that this example is an excellent example to show (almost) all the
>> iss
Hi all:
This patch enables -march/-mtune=yongfeng, costs and tunings are set
according to the characteristics of the processor. We add a new md file to
describe yongfeng processor.
Bootstrapped /regtested X86_64.
Ok for trunk?
BR
Mayshao
gcc/ChangeLog:
* common/config/i386/
101 - 129 of 129 matches
Mail list logo
