On Mon, Mar 10, 2025 at 11:33 AM Fangrui Song wrote:
> >> (lld has a quite simple model where undefined non-weak and undefined
> >> weak symbols are handled in a unified way.
> >> A symbol is preemptible if:
> >>
> >> * -shared or at least on
10358: 000e0367 jalr t1,t3
>1035c: 0013 nop
>
> Disassembly of section .text:
>
> 00010360 <_start>:
>10360: 0097 auipc ra,0x0
>10364: ca0080e7 jalr -864(ra) # 0
> <_PROCEDURE_LINKAGE_TABLE
jal 10330
1036c: 0097 auipc ra,0x0
10370: 00e7 jalr zero # 0
<_PROCEDURE_LINKAGE_TABLE_-0x10310>
(lld has a quite simple model where undefined non-weak and undefined
> weak symbols are handled in a unified way.
> A symbol is preemptible if:
On Thu, Mar 6, 2025 at 7:05 PM Nelson Chu wrote:
>
> Committed, thanks.
>
> Nelson
>
> On Mon, Mar 3, 2025 at 11:51 AM Nelson Chu wrote:
>>
>> Looks like we could give it a try and see if it works and won't affect
>> current projects. I will comm
Committed, thanks.
Nelson
On Mon, Mar 3, 2025 at 11:51 AM Nelson Chu wrote:
> Looks like we could give it a try and see if it works and won't affect
> current projects. I will commit it before this weekend if there are no
> objections.
>
> Thanks
> Nelson
>
> On
Looks like we could give it a try and see if it works and won't affect
current projects. I will commit it before this weekend if there are no
objections.
Thanks
Nelson
On Tue, Feb 11, 2025 at 1:53 AM Palmer Dabbelt wrote:
> On Sat, 08 Feb 2025 00:33:37 PST (-0800), Nelson Chu wrote:
&
and will go through a few bugs to see where
I can reasonably add this.
Fortran is a complicated language, and quite often the question is not
if a program is illegal or not, but what it should do.
Best regards
Thomas
Thomas Koenig via Gcc writes:
> Hello world,
>
> looking at a few Fortran bug reports, I found some cases where
> it was not clear if the program in question was standard-conforming
> or not. I would propose to add a keyword for that, tentatively
> called "interp".
&
Hi!
On 2025-02-10T20:59:43+0100, Thomas Koenig wrote:
> Am 10.02.25 um 08:43 schrieb Richard Biener:
>> We have need-bisection and other need-, so iff then maybe a need-stdchk for
>> cases compliance is unclear?
>
> That sounds very good to me; if there are no objections, I
On Mon, 2025-02-10 at 09:29 +, Jonathan Wakely via Gcc wrote:
> On Sun, 9 Feb 2025, 09:08 Thomas Koenig via Gcc,
> wrote:
>
> > Hello world,
> >
> > looking at a few Fortran bug reports, I found some cases where
> > it was not clear if the program in questi
Am 10.02.25 um 21:05 schrieb David Malcolm:
FWIW my first thought for "interp" was that we gaining an interpreter
(there are some in the libgccjit test suite).
It was motivated by Fortran interps, which are interpretation requrests.
But I think that Richard's suggestion, neeeds-stdcheck, makes
Am 10.02.25 um 08:43 schrieb Richard Biener:
We have need-bisection and other need-, so iff then maybe a need-stdchk for
cases compliance is unclear?
That sounds very good to me; if there are no objections, I will create
this in a day or so.
The fact that a testcase is (non-)compliant is
undefined (weak) symbol, when building an dynamic executable. I think
the pic/pie behavior won't be affected as usual. I am not sure if the change
will cause trouble or not for other projects, so please feels free to cc people
that you think they will be affected, thanks.
Thanks for doing
On Sun, 9 Feb 2025, 09:08 Thomas Koenig via Gcc, wrote:
> Hello world,
>
> looking at a few Fortran bug reports, I found some cases where
> it was not clear if the program in question was standard-conforming
> or not. I would propose to add a keyword for that, tentatively
&
t help in bug searches.
Richard.
> - Andre
>
> On Sun, 9 Feb 2025 09:00:47 -0800
> Jerry D wrote:
>
> > On 2/9/25 1:07 AM, Thomas Koenig wrote:
> > > Hello world,
> > >
> > > looking at a few Fortran bug reports, I found some cases where
>
/9/25 1:07 AM, Thomas Koenig wrote:
> > Hello world,
> >
> > looking at a few Fortran bug reports, I found some cases where
> > it was not clear if the program in question was standard-conforming
> > or not. I would propose to add a keyword for that, tentatively
> &g
On 2/9/25 1:07 AM, Thomas Koenig wrote:
Hello world,
looking at a few Fortran bug reports, I found some cases where
it was not clear if the program in question was standard-conforming
or not. I would propose to add a keyword for that, tentatively
called "interp".
Comments? Suggest
Hello world,
looking at a few Fortran bug reports, I found some cases where
it was not clear if the program in question was standard-conforming
or not. I would propose to add a keyword for that, tentatively
called "interp".
Comments? Suggestions for a different name? Should I jus
e. I think
the pic/pie behavior won't be affected as usual. I am not sure if the change
will cause trouble or not for other projects, so please feels free to cc people
that you think they will be affected, thanks.
---
bfd/elfnn-riscv.c | 84 +--
> Am 30.11.2024 um 08:19 schrieb Mateusz Guzik via Gcc :
>
> Tested with gcc 14.2 and the Linux kernel compiling for amd64. This is
> at Linux next-20241127. This was already the case on gcc 13 (no idea
> about earlier versions), I tested 14 to see if the problem is go
Tested with gcc 14.2 and the Linux kernel compiling for amd64. This is
at Linux next-20241127. This was already the case on gcc 13 (no idea
about earlier versions), I tested 14 to see if the problem is gone.
In the particular case I ran into a prediction concerning the return
value of __access_ok
r a constant, say width == 100 we do:
> >
> > (set_scalar_evolution
> > instantiated_below = 2
> > (scalar = sum_6)
> > (scalar_evolution = {0, +, {1, +, 1}_1}_1))
> > )
> > (chrec_apply
> > (varying_loop = 1)
> > (chrec = {0, +, {1,
to compute the final value of the reduction.
>
> For a constant, say width == 100 we do:
>
> (set_scalar_evolution
> instantiated_below = 2
> (scalar = sum_6)
> (scalar_evolution = {0, +, {1, +, 1}_1}_1))
> )
> (chrec_apply
> (varying_loop = 1)
> (chrec
ns = 0;
> > > int width = rand() % 16;
> > > for (int j = 0; j < width; j++)
> > > ans += 1 << (j + width)
> > >
> > > into:
> > >
> > > int width = rand() % 16;
> > > ans = (1 << (2 * width) - (1 << width));
&g
t j = 0; j < width; j++)
> > ans += 1 << (j + width)
> >
> > into:
> >
> > int width = rand() % 16;
> > ans = (1 << (2 * width) - (1 << width));
> >
> > I came across a more complex version of that and found that gcc
> > doe
>>> wrote:
>>>>>>>
>>>>>>> Hi, I'm trying to make pass_fre work better for me. But I got a
>>>>>>> problem. Like the code below:
>>>>>>>
>>>>>>> int glob;
>>>>>>
etter for me. But I got a
> >>>>> problem. Like the code below:
> >>>>>
> >>>>> int glob;
> >>>>>
> >>>>> void __attribute__((oninline))
> >>>>> foo() {
> >>>>> // do nothing meaningfu
t;>>>> On Fri, Oct 20, 2023 at 1:48 PM Hanke Zhang via Gcc
>>>>> wrote:
>>>>>
>>>>> Hi, I'm trying to make pass_fre work better for me. But I got a
>>>>> problem. Like the code below:
>>>>>
>>>>>
t;
> >>> Hi, I'm trying to make pass_fre work better for me. But I got a
> >>> problem. Like the code below:
> >>>
> >>> int glob;
> >>>
> >>> void __attribute__((oninline))
> >>> foo() {
&g
>> problem. Like the code below:
>>>
>>> int glob;
>>>
>>> void __attribute__((oninline))
>>> foo() {
>>> // do nothing meaningful
>>> }
>>>
>>> int main() {
>>> if (glob) {
>>>foo();
>>
tribute__((oninline))
> > foo() {
> > // do nothing meaningful
> > }
> >
> > int main() {
> > if (glob) {
> > foo();
> > } else {
> > // do something that won't change glob
> > }
> >
> > if (glob) {
> &
On Fri, Oct 20, 2023 at 1:48 PM Hanke Zhang via Gcc wrote:
>
> Hi, I'm trying to make pass_fre work better for me. But I got a
> problem. Like the code below:
>
> int glob;
>
> void __attribute__((oninline))
> foo() {
> // do nothing meaningful
> }
>
&g
Hi, I'm trying to make pass_fre work better for me. But I got a
problem. Like the code below:
int glob;
void __attribute__((oninline))
foo() {
// do nothing meaningful
}
int main() {
if (glob) {
foo();
} else {
// do something that won't change glob
}
if (glob)
hat gcc
> doesn't seem to handle it, so wanted to write a pass myself to
> optimize it.
>
> I got two questions here. Does GCC have such optimizations? If I want
> to do my own optimization, where should I put it? Put it behind the
> pass_iv_optimize?
GCC has the final val
lt; (j + width)
into:
int width = rand() % 16;
ans = (1 << (2 * width) - (1 << width));
I came across a more complex version of that and found that gcc
doesn't seem to handle it, so wanted to write a pass myself to
optimize it.
I got two questions here. Does GCC have such optimi
mple, for the following code:
> >
> > int main() {
> > int size = 1000;
> > int *foo = malloc(sizeof(int) * size);
> > int c1 = rand(), t1 = rand();
> >
> > for (int i = 0; i < size; i++) {
> > if (foo[i] & c1) {
> > foo[i] = t1;
> > > problem and would like to ask for advice.
> > >
> > > For example, for the following code:
> > >
> > > int main() {
> > > int size = 1000;
> > > int *foo = malloc(sizeof(int) * size);
> > > int c1 = ra
int *foo = malloc(sizeof(int) * size);
> int c1 = rand(), t1 = rand();
>
> for (int i = 0; i < size; i++) {
> if (foo[i] & c1) {
> foo[i] = t1;
> }
> }
>
> // prevents the loop above from being optimized
> for (int i = 0; i < size; i+
On 10/14/23 09:49, Andrew Pinski via Gcc wrote:
On Fri, Oct 13, 2023 at 10:16 PM Hanke Zhang via Gcc wrote:
Hi, I'm working on optimizing if-conversion for my own business
recently. I got a problem here.
I tried to optimize it in such a case, for example, when a conditional
stat
On Fri, Oct 13, 2023 at 10:16 PM Hanke Zhang via Gcc wrote:
>
> Hi, I'm working on optimizing if-conversion for my own business
> recently. I got a problem here.
>
> I tried to optimize it in such a case, for example, when a conditional
> statement block has only i
Hi, I'm working on optimizing if-conversion for my own business
recently. I got a problem here.
I tried to optimize it in such a case, for example, when a conditional
statement block has only if statement and no else statement, the
source C code looks like this:
int* foo; // assume this has
< size; i++) {
if (foo[i] & c1) {
foo[i] = t1;
}
}
// prevents the loop above from being optimized
for (int i = 0; i < size; i++) {
printf("%d", foo[i]);
}
}
First of all, the if statement block in the loop will be converted to
a MASK_STORE through if-conversio
printf might call back into the current TU and modify globals in such
> callback. That's a GNU extension to printf that ICC likely doesn't
> support
> (https://www.gnu.org/software/libc/manual/html_node/Customizing-Printf.html),
> so that we're currently not doing this
On Sun, Oct 1, 2023 at 6:13 AM Hanke Zhang wrote:
>
> Richard Biener 于2023年9月27日周三 15:30写道：
> >
> > On Wed, Sep 27, 2023 at 7:21 AM Hanke Zhang via Gcc wrote:
> > >
> > > Thanks! I understand what you mean, then can I think that if the
> > > fun
Richard Biener 于2023年9月27日周三 15:30写道：
>
> On Wed, Sep 27, 2023 at 7:21 AM Hanke Zhang via Gcc wrote:
> >
> > Thanks! I understand what you mean, then can I think that if the
> > function here is not an external function, but a function visible to
> > the compiler a
On Wed, Sep 27, 2023 at 7:21 AM Hanke Zhang via Gcc wrote:
>
> Thanks! I understand what you mean, then can I think that if the
> function here is not an external function, but a function visible to
> the compiler and the function doesn't modify `a`, then these two
> blocks
Thanks! I understand what you mean, then can I think that if the
function here is not an external function, but a function visible to
the compiler and the function doesn't modify `a`, then these two
blocks can be merged?
Marc Glisse 于2023年9月27日周三 12:51写道：
>
> On Wed, 27 Sep 2023, Hank
On Wed, 27 Sep 2023, Hanke Zhang via Gcc wrote:
Hi, I have recently been working on merging if-else statement blocks,
and I found a rather bizarre phenomenon that I would like to ask
about.
A rough explanation is that for two consecutive if-else blocks, if
their if statements are exactly the
Hi, I have recently been working on merging if-else statement blocks,
and I found a rather bizarre phenomenon that I would like to ask
about.
A rough explanation is that for two consecutive if-else blocks, if
their if statements are exactly the same, they should be merged, like
the following
On Sun, 12 Feb 2023 at 20:46, David Shane Holden via Gcc
wrote:
>
> I requested a bugzilla account a few days ago and haven't heard
> back so I'm just going to report this here.
I've created your account now, so please post this to bugzilla, thanks!
*a, const uint8_t *b) {
return __builtin_mul_overflow(*a, *b, r);
}
int main() {
uint8_t x;
/* 64 + 64 should not overflow */
x = 64;
if (add(&x, &x, &x))
printf("false positive: x=%i\n", x);
/* 4 * 4 should not overflow */
x = 4;
if (mul(&x, &x, &am
On 10/19/22 01:46, Richard Biener wrote:
On Wed, Oct 19, 2022 at 5:44 AM Jeff Law via Gcc wrote:
On 10/18/22 20:09, Vineet Gupta wrote:
On 10/18/22 16:36, Jeff Law wrote:
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we
On Wed, Oct 19, 2022 at 5:44 AM Jeff Law via Gcc wrote:
>
>
> On 10/18/22 20:09, Vineet Gupta wrote:
> >
> > On 10/18/22 16:36, Jeff Law wrote:
> >>>> There isn't a great place in GCC to handle this right now. If the
> >>>> const
On 10/18/22 20:09, Vineet Gupta wrote:
On 10/18/22 16:36, Jeff Law wrote:
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we'd have a chance, but
getting the cost model right is going to be tough.
It would have been better
On 10/18/22 16:36, Jeff Law wrote:
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we'd have a chance, but
getting the cost model right is going to be tough.
It would have been better (for this specific case) if loop unro
solves which gives it the
answer to that question. The one that computes this property is usually
called anticipated. Given some block B in a graph G. An expression is
anticipated at B when the expression is guaranteed to be computed if we
reach B. That doesn't mean the evaluation must happe
valuations.
OK. How does PRE calculate all possible paths to consider: say your
example 2-3-4-5 and 2-4-6 ? Is that just indicative or would actually be
the one PRE calculates for this case. Would there be more ?
There isn't a great place in GCC to handle this right now. If the
constraints
On 10/14/22 09:56, Vineet Gupta wrote:
Hi,
When analyzing coremark build for RISC-V, noticed redundant constants
not being eliminated. While this is a recurrent issue with RV, this
specific instance is not unique to RV as I can trigger similar output
on aarch64 with -fno-if-conversion
Hi,
When analyzing coremark build for RISC-V, noticed redundant constants
not being eliminated. While this is a recurrent issue with RV, this
specific instance is not unique to RV as I can trigger similar output on
aarch64 with -fno-if-conversion, hence something which could be
addressed in
I suppose I should answer my own question
Yes, the final compiler built has ubsan enabled.
Gary
PS. The faint hearted should note this is an overnight build. It would be nice
if this wasn't tied to building a bootstrap compiler.
From: Gary Oblock
er 27, 2021 11:47 PM
To: Erick Ochoa ; Gary Oblock
Cc: gcc@gcc.gnu.org
Subject: Re: Can gcc itself be tested with ubsan? If so, how?
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Tue, Sep 28, 2021 at 2:48 AM Toon Moene wrote:
>
> On 9/28/21 8:35 AM, Erick Ochoa via Gcc wrote:
>
> >> Can ubsan be used on the compiler itself?
>
> I regularly build the compiler(s) natively with ubsan enabled, see for
> instance:
>
> https://gcc.gnu.org/pipermail/gcc-testresults/2021-Septem
On 9/28/21 8:35 AM, Erick Ochoa via Gcc wrote:
Can ubsan be used on the compiler itself?
I regularly build the compiler(s) natively with ubsan enabled, see for
instance:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-September/719448.html
The configure line tells you how to do it (towa
Hi,
just as a note. This is also of interest to me. I have wanted to
compile a single pass that I wrote using ubsan/other sanitizers for
testing purposes. I was wondering if someone has already modified the
build system to use ubsan to test their passes and if they could
document the process for
ins information that is
confidential and proprietary to Ampere Computing or its subsidiaries. It is to
be used solely for the purpose of furthering the parties' business
relationship. Any unauthorized review, copying, or distribution of this email
(or any attachments thereto) is strictly prohibited.
unlvsur unlvsur wrote:
<3E6B1CF4201340D8BCCB373AE127FCC7.png>
Sent from Mail for Windows 10
The -stdlib= option is an “enabling” change;
As things stand, the packaging of the libc++ headers (and libc++ itself)
needs intervention by the distribution (e.g. to add a coroutine header or
to
Am 05.12.2020 um 14:25 schrieb Eric Botcazou:
> can someone explain to me why the -O2 optimizer is not able(allowed) to
> reduce this small sample the same way as clang/msvc?
Change the name of the function to something else than "main".
that works, thanks!
Am 05.12.2020 um 13:04 schrieb Jan Hubicka:
> gcc does not reduce to call result if called function is not static in
> -O2 (will do with -O2)
> clang and msvc does it also in -O2 regardless of the function beeing
> static or not
>
> can someone explain to me why the -O2 opt
> can someone explain to me why the -O2 optimizer is not able(allowed) to
> reduce this small sample the same way as clang/msvc?
Change the name of the function to something else than "main".
--
Eric Botcazou
> gcc does not reduce to call result if called function is not static in
> -O2 (will do with -O2)
> clang and msvc does it also in -O2 regardless of the function beeing
> static or not
>
> can someone explain to me why the -O2 optimizer is not able(allowed) to
> reduce this
gcc does not reduce to call result if called function is not static in
-O2 (will do with -O2)
clang and msvc does it also in -O2 regardless of the function beeing
static or not
can someone explain to me why the -O2 optimizer is not able(allowed) to
reduce this small sample the same way as clang
@@gcc/final.c
> > void
> > output_operand (rtx x, int code ATTRIBUTE_UNUSED)
> > {
> > if (x && GET_CODE (x) == SUBREG)
> > x = alter_subreg (&x, true);
> >
> > /* X must not be a pseudo reg. */
> &
"Hu, Jiangping" writes:
> Hi,
>
> I find there are many "ATTRIBUTE_UNUSED" macros in the function parameter
> lists,
> but some of the parameters are used in the function bodies in fact. E.g.
>
> @@gcc/final.c
> void
> output_operand (rtx
Hi,
I find there are many "ATTRIBUTE_UNUSED" macros in the function parameter lists,
but some of the parameters are used in the function bodies in fact. E.g.
@@gcc/final.c
void
output_operand (rtx x, int code ATTRIBUTE_UNUSED)
{
if (x && GET_CODE (x)
Hi,
As subject, how should I check if a type can be contextually converted
to bool, in c++FE?
Thanks,
bin
Greetings,
Did you received my message?let me know.
Best Regards,
Mr.Abdelkader Alsamman.
:
>>>>> More generally, we can rewrite
>>>>>
>>>>> if ( x > ((1 << z) -1)) { ...}
>>>>>
>>>>> as
>>>>>
>>>>> if ( x >> z ) { ... }
>>>>>
>>>>> This d
On Sat, Jun 22, 2019 at 03:30:15PM -0600, Jeff Law wrote:
> On 6/22/19 12:44 PM, Segher Boessenkool wrote:
> > On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote:
> >> On 6/22/19 7:55 AM, Jason Duerstock wrote:
> >>> More generally, we can rewrite
>
On 6/22/19 12:44 PM, Segher Boessenkool wrote:
> On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote:
>> On 6/22/19 7:55 AM, Jason Duerstock wrote:
>>> More generally, we can rewrite
>>>
>>> if ( x > ((1 << z) -1)) { ...}
>>>
>>>
On Sat, Jun 22, 2019 at 09:46:52AM -0600, Jeff Law wrote:
> On 6/22/19 7:55 AM, Jason Duerstock wrote:
> > More generally, we can rewrite
> >
> > if ( x > ((1 << z) -1)) { ...}
> >
> > as
> >
> > if ( x >> z ) { ... }
> >
>
On 6/22/19 7:55 AM, Jason Duerstock wrote:
> I was starting at the assembly from some of the Python source, and
> came across this (simplified) comparison:
>
> if (x > 2305843009213693951) {...}
>
> This is the same as:
>
> if (x > 0x1fff) {...}
>
I was starting at the assembly from some of the Python source, and
came across this (simplified) comparison:
if (x > 2305843009213693951) {...}
This is the same as:
if (x > 0x1fff) {...}
This is equivalent to:
if (x >> 61) {...}
More generally, we can rewrite
if (
Hi Boris,
On Sat, Aug 12, 2017 at 05:53:44PM +0200, Boris Kolpackov wrote:
> Segher Boessenkool writes:
>
> > Patches should go to gcc-patches.
>
> Ok, will keep in mind for future (seeing that we have a discussion
> already it probably doesn't make sense to move this patch).
Please do move it
Boris
Index: gcc/c-family/ChangeLog
===
--- gcc/c-family/ChangeLog (revision 250514)
+++ gcc/c-family/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2017-08-06 Boris Kolpackov
+
+ * c-opts.c (c_common_finish): Write dependency informat
y on such a header).
Good point. I've tested this and I believe everything is in order:
unless -MG is specified, a non-existent header is treated as a fatal
error so we don't even get to writing the dependency info. And if -MG
is specified, then there is no error and we get the missing hea
On Wed, 9 Aug 2017, Jeff Law wrote:
> This directly reverts part of Joseph's changes from 2009. I'd like to
> hear from him on this change.
The point of those changes was to make cpplib diagnostics use the
compiler's diagnostic machinery rather than a separate set of diagnostic
machinery in c
On 08/06/2017 01:59 AM, Boris Kolpackov wrote:
> Hi,
>
> Currently GCC does not write extracted header dependency information
> if there are errors. However, this can be useful when dealing with
> outdated generated headers that trigger errors which would have been
> resolved
Hi!
Patches should go to gcc-patches.
Just a trivial remark:
> --- gcc/c-family/c-opts.c (revision 250514)
> +++ gcc/c-family/c-opts.c (working copy)
> @@ -1152,8 +1152,11 @@
> {
>FILE *deps_stream = NULL;
>
> - /* Don't write the deps file if the
Hi,
Currently GCC does not write extracted header dependency information
if there are errors. However, this can be useful when dealing with
outdated generated headers that trigger errors which would have been
resolved if we could update it. A concrete example in our case is a
version check with
Hi GCC developers,
As ChangeLog-2014 mentioned: Remove support for if_marked and param_is
about ggc, so I migrate to GCC v6.x, for example:
#if (GCC_MAJOR < 6)
// FIXME: gengtype not support macro?
//static GTY((if_marked("tree2int_marked_p"), param_is(struct tree2int)))
Dear Valued Member
With the Holidays almost here and 2017 just around the corner, it is very
important to get your online business in a position of being found on major
search engines. Now a days, it's not only about keywords anymore, it's about
branding your company through a very complex m
rd Biener wrote:
>> >>>
>> >>> On Wed, 12 Oct 2016, Marc Glisse wrote:
>> >>>
>> >>>> On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote:
>> >>>>
>> >>>>> I was having a look at PR71636 and added the fol
c Glisse wrote:
> >>>
> >>>> On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote:
> >>>>
> >>>>> I was having a look at PR71636 and added the following pattern to
> >>>>> match.pd:
> >>>>> x & ((1U <<
h Kulkarni wrote:
>>>>
>>>>> I was having a look at PR71636 and added the following pattern to
>>>>> match.pd:
>>>>> x & ((1U << b) - 1) -> x & ~(~0U << b)
>>>>> However the transform is useful only if
- 1) -> x & ~(~0U << b)
However the transform is useful only if the target supports "andnot"
instruction.
rth was selling the transformation as a canonicalization, which is beneficial
when there is an andnot instruction, and neutral otherwise, so it could be
done always.
t; b) - 1) -> x & ~(~0U << b)
>> > However the transform is useful only if the target supports "andnot"
>> > instruction.
>>
>> rth was selling the transformation as a canonicalization, which is beneficial
>> when there is an andnot ins
On Wed, 12 Oct 2016, Marc Glisse wrote:
> On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote:
>
> > I was having a look at PR71636 and added the following pattern to match.pd:
> > x & ((1U << b) - 1) -> x & ~(~0U << b)
> > However the transfor
On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote:
I was having a look at PR71636 and added the following pattern to match.pd:
x & ((1U << b) - 1) -> x & ~(~0U << b)
However the transform is useful only if the target supports "andnot"
instruction.
rth wa
On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote:
> Hi,
> I was having a look at PR71636 and added the following pattern to match.pd:
> x & ((1U << b) - 1) -> x & ~(~0U << b)
> However the transform is useful only if the target supports "andnot"
>
1 - 100 of 453 matches
Mail list logo
