No warning for module global variable which is set but never used

2020-12-09 Thread webmaster 
Hello,I'm wondering why GCC does not throw any warning when a module global 
variable is set (write) but never used (read).Is this behavior wanted? Does it 
makes sense to add such warning?Greets

Re: No warning for module global variable which is set but never used

2020-12-09 Thread Jonathan Wakely via Gcc 
On Wed, 9 Dec 2020 at 09:28, webmaster  wrote:
>
> Hello,I'm wondering why GCC does not throw any warning when a module global 
> variable is set (write) but never used (read).Is this behavior wanted? Does 
> it makes sense to add such warning?Greets

This question seems to be more appropriate for the gcc-help list.
Please take any replies to that list instead.

What do you mean by "module"? A Fortran module? A C++ module? Or do
you just mean a source file?

In C and C++ global variables have external linkage by default, which
means they can be accessed from another translation unit (i.e. another
source file). Unless the compiler knows that the entire program is a
single source file, it can't know that there aren't writes to the
variable in other files.

Re: No warning for module global variable which is set but never used

2020-12-09 Thread David Brown 
On 09/12/2020 10:25, webmaster wrote:
> Hello,I'm wondering why GCC does not throw any warning when a module global 
> variable is set (write) but never used (read).Is this behavior wanted? Does 
> it makes sense to add such warning?Greets
> 

How do you expect the compiler to know if the variable is never read?

If it has file linkage (it is declared "static") and its address is not
taken and exported out of the translation unit, then the compiler knows
all about it - and could warn about it.  If it has external linkage
(declared at file scope without "static", or with "extern") or its
address is passed out of the translation unit, then the compiler has no
way to tell how it might be used in other translation units.


If you write:

static int xx;
void foo(void) {
xx = 2;
}

then gcc will eliminate the variable "xx" entirely, as it is never used.
 The function "foo" is compiled to a single "return".  But no
"unused-but-set-variable" warning is emitted - and clearly the compiler
knows that the variable is set but not used.  (You get the warning if
the static variable is local to the function.)

I'd say that it makes sense to have such a warning as a natural
enhancement to the existing "-Wunused-but-set-variable" warning.  But I
can't say if it is a simple matter or not - sometimes these things are
surprisingly difficult to implement depending on the order of passes in
the compiler.  Then it becomes a trade-off of the utility of such a
warning against the effort needed to implement it.

Re: No warning for module global variable which is set but never used

2020-12-09 Thread Jakub Jelinek via Gcc 
On Wed, Dec 09, 2020 at 10:50:22AM +0100, David Brown wrote:
> I'd say that it makes sense to have such a warning as a natural
> enhancement to the existing "-Wunused-but-set-variable" warning.  But I

That is not really possible.
The -Wunused-but-set-* warning works by having two bits for the DECL,
TREE_USED and DECL_READ_P, where any uses mark the var TREE_USED and
(conservatively) what can read the value marks it DECL_READ_P
and -Wunused-but-set-* is then variables that are TREE_USED and
!DECL_READ_P.  All this needs to be done early in the FE.
For the static vars, the optimization to remove them altogether is done
much later, and at that point the compiler doesn't know if it isn't used
because all the reads in the program have been optimized away vs. there were
none.

Jakub

Re: No warning for module global variable which is set but never used

2020-12-09 Thread David Brown 
On 09/12/2020 11:00, Jakub Jelinek wrote:
> On Wed, Dec 09, 2020 at 10:50:22AM +0100, David Brown wrote:
>> I'd say that it makes sense to have such a warning as a natural
>> enhancement to the existing "-Wunused-but-set-variable" warning.  But I
> 
> That is not really possible.
> The -Wunused-but-set-* warning works by having two bits for the DECL,
> TREE_USED and DECL_READ_P, where any uses mark the var TREE_USED and
> (conservatively) what can read the value marks it DECL_READ_P
> and -Wunused-but-set-* is then variables that are TREE_USED and
> !DECL_READ_P.  All this needs to be done early in the FE.
> For the static vars, the optimization to remove them altogether is done
> much later, and at that point the compiler doesn't know if it isn't used
> because all the reads in the program have been optimized away vs. there were
> none.
> 
>   Jakub
> 

That's what I thought might be the case.  I've seen this before in
situations where it might seem to the layman that it is "obvious" that
there should be a warning here, or that "the compiler can optimise here,
surely it can also issue a warning".  If it were easy to implement a
warning in a situation like this, I guess the gcc developers would have
implemented it already!

I hope this gives the OP the information he is looking for.

David

Re: [EXTERNAL]Re: MIPS Maintainer

2020-12-09 Thread Maciej W. Rozycki 
On Tue, 8 Dec 2020, Chao-ying Fu wrote:

> >  Well, it's up to the GCC steering committee really to appoint maintainers 
> > , however you can post patches and help 
> > with getting reviews through right away.  There hasn't been much traffic 
> > with the MIPS port recently, but there has been some and it always helps 
> > to have someone provide input.
> 
>   I got David Edelsohn's email and replied to him yesterday.
> We have some small tweaks in GCC and can send the patches.

 Please note that GCC is in Stage 3 as from Nov 16th, so if these are bug 
fixes, then they may still qualify for inclusion with the upcoming GCC 11 
release expected May-ish next year, but you need to hurry and submit them 
ASAP.  Otherwise you'll have to wait until trunk reopens for general 
development around the time of the release.

 See:  for the release pattern and: 
 for the most 
recent status (always linked from the:  home page).

> There is a big patch for nanoMIPS that stays as-is for long time.
> It will take time to get the patch working against the latest code base,
> if the community wants to include nanoMIPS in GCC.

 I am glad this has not been lost, contrary to the fears I have expressed 
in a discussion on the MIPS/NetBSD mailing list as recently as last week.

 This is however a major new feature, so it will definitely have to wait 
for Stage 1.  You may post the patch(es) regardless, however they may not 
attract much attention as people are busy with QA for GCC 11, especially 
as in the current situation it is likely it will have to be a general 
maintainer to approve such a change.  Mind that given how it has been 
defined the nanoMIPS ISA might be considered an entirely new port/platform 
though it will depend on how the support for it has been wired into GCC (I 
don't know the details myself, I wasn't following that development).

 Also you will have to have binutils support approved and committed first, 
and given their semiannual release schedule you may well start working on 
a submission right away, so that at least you have a chance to have that 
included with the Jul 2021 release (surely you won't make it for the Jan 
2021 one).

 David has kindly explained the rest: just post the changes and have them 
reviewed, and it's up to the community to decide if a new maintainer is 
required and if so, who will that be.

 And last but not least, please make sure you are covered by a copyright 
assignment with FSF under your current employment.

  Maciej

Re: Help with PR97872

2020-12-09 Thread Prathamesh Kulkarni via Gcc 
On Tue, 8 Dec 2020 at 14:36, Prathamesh Kulkarni
 wrote:
>
> On Mon, 7 Dec 2020 at 17:37, Hongtao Liu  wrote:
> >
> > On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
> >  wrote:
> > >
> > > On Mon, 7 Dec 2020 at 16:15, Hongtao Liu  wrote:
> > > >
> > > > On Mon, Dec 7, 2020 at 5:47 PM Richard Biener  wrote:
> > > > >
> > > > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> > > > >
> > > > > > On Mon, 7 Dec 2020 at 13:01, Richard Biener  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > > >
> > > > > > > > On Fri, 4 Dec 2020 at 17:18, Richard Biener  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Fri, 4 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > > > > >
> > > > > > > > > > On Thu, 3 Dec 2020 at 16:35, Richard Biener 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 3 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On Tue, 1 Dec 2020 at 16:39, Richard Biener 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, 1 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > For the test mentioned in PR, I was trying to see 
> > > > > > > > > > > > > > if we could do
> > > > > > > > > > > > > > specialized expansion for vcond in target when 
> > > > > > > > > > > > > > operands are -1 and 0.
> > > > > > > > > > > > > > arm_expand_vcond gets the following operands:
> > > > > > > > > > > > > > (reg:V8QI 113 [ _2 ])
> > > > > > > > > > > > > > (reg:V8QI 117)
> > > > > > > > > > > > > > (reg:V8QI 118)
> > > > > > > > > > > > > > (lt (reg/v:V8QI 115 [ a ])
> > > > > > > > > > > > > > (reg/v:V8QI 116 [ b ]))
> > > > > > > > > > > > > > (reg/v:V8QI 115 [ a ])
> > > > > > > > > > > > > > (reg/v:V8QI 116 [ b ])
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > where r117 and r118 are set to vector constants -1 
> > > > > > > > > > > > > > and 0 respectively.
> > > > > > > > > > > > > > However, I am not sure if there's a way to check if 
> > > > > > > > > > > > > > the register is
> > > > > > > > > > > > > > constant during expansion time (since we don't have 
> > > > > > > > > > > > > > df analysis yet) ?
> > > >
> > > > It seems to me that all you need to do is relax the predicates of op1
> > > > and op2 in vcondmn to accept const0_rtx and constm1_rtx. I haven't
> > > > debugged it, but I see that vcondmn in neon.md only accepts
> > > > s_register_operand.
> > > >
> > > > (define_expand "vcond"
> > > >   [(set (match_operand:VDQW 0 "s_register_operand")
> > > > (if_then_else:VDQW
> > > >   (match_operator 3 "comparison_operator"
> > > > [(match_operand:VDQW 4 "s_register_operand")
> > > >  (match_operand:VDQW 5 "reg_or_zero_operand")])
> > > >   (match_operand:VDQW 1 "s_register_operand")
> > > >   (match_operand:VDQW 2 "s_register_operand")))]
> > > >   "TARGET_NEON && (! || flag_unsafe_math_optimizations)"
> > > > {
> > > >   arm_expand_vcond (operands, mode);
> > > >   DONE;
> > > > })
> > > >
> > > > in sse.md it's defined as
> > > > (define_expand "vcondu"
> > > >   [(set (match_operand:V_512 0 "register_operand")
> > > > (if_then_else:V_512
> > > >   (match_operator 3 ""
> > > > [(match_operand:VI_AVX512BW 4 "nonimmediate_operand")
> > > >  (match_operand:VI_AVX512BW 5 "nonimmediate_operand")])
> > > >   (match_operand:V_512 1 "general_operand")
> > > >   (match_operand:V_512 2 "general_operand")))]
> > > >   "TARGET_AVX512F
> > > >&& (GET_MODE_NUNITS (mode)
> > > >== GET_MODE_NUNITS (mode))"
> > > > {
> > > >   bool ok = ix86_expand_int_vcond (operands);
> > > >   gcc_assert (ok);
> > > >   DONE;
> > > > })
> > > >
> > > > then we can get operands[1] and operands[2] as
> > > >
> > > > (gdb) p debug_rtx (operands[1])
> > > >  (const_vector:V16QI [
> > > > (const_int -1 [0x]) repeated x16
> > > > ])
> > > > (gdb) p debug_rtx (operands[2])
> > > > (reg:V16QI 82 [ _2 ])
> > > > (const_vector:V16QI [
> > > > (const_int 0 [0]) repeated x16
> > > > ])
> > > Hi Hongtao,
> > > Thanks for the suggestions!
> > > However IIUC from vector extensions doc page, the result of vector
> > > comparison is defined to be 0
> > > or -1, so would it be better to canonicalize
> > > x cmp y ? -1 : 0 to x cmp y, on GIMPLE itself during gimple-isel and
> > > adjust targets if required ?
> >
> > Yes, it would be more straightforward to handle it in gimple isel, I
> > would adjust the backend and testcase after you check in the patch.
> Thanks! I have committed the attached patch in
> 3a6e3ad38a17a03ee0139b49a0946e7b9ded1eb1.
Hi,
I was looking at similar issue in PR97903 and wondering what will be the
right approach to lower (a & b) != 0 to vtst ?
For test-case:
#include 

int8x8_t f1(int8x8_t a, int8x8_t b) {
  return (a & b

Re: No warning for module global variable which is set but never used

2020-12-09 Thread webmaster 
Ahh, ok. With these explanation I understand that the compiler does remove it 
because of optimatizion. This is somehow good and bad.  Good that unused 
variable does not consume any memory. Bad that developer is not informed that 
variable can be removed.
 Ursprüngliche Nachricht Von: Jakub Jelinek  
Datum: 09.12.20  11:00  (GMT+01:00) An: David Brown  Cc: 
webmaster , gcc@gcc.gnu.org Betreff: Re: No warning 
for module global variable which is set but never used On Wed, Dec 09, 2020 at 
10:50:22AM +0100, David Brown wrote:> I'd say that it makes sense to have such 
a warning as a natural> enhancement to the existing "-Wunused-but-set-variable" 
warning.  But IThat is not really possible.The -Wunused-but-set-* warning works 
by having two bits for the DECL,TREE_USED and DECL_READ_P, where any uses mark 
the var TREE_USED and(conservatively) what can read the value marks it 
DECL_READ_Pand -Wunused-but-set-* is then variables that are TREE_USED 
and!DECL_READ_P.  All this needs to be done early in the FE.For the static 
vars, the optimization to remove them altogether is donemuch later, and at that 
point the compiler doesn't know if it isn't usedbecause all the reads in the 
program have been optimized away vs. there werenone. Jakub

Possible leaks observed in GCC.

2020-12-09 Thread Tomar, Sourabh Singh via Gcc 
Hi Folks,

I observed some leaks using valgrind while compiling a sample program using GCC.

Could anyone aware of these details provide any insights to these leaks ?

Command line Details:
$ valgrind gcc main.c -g
==32090== Memcheck, a memory error detector
==32090== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==32090== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==32090== Command: gcc main.c -g
==32090==
==32090==
==32090== HEAP SUMMARY:
==32090== in use at exit: 171,779 bytes in 101 blocks
==32090==   total heap usage: 394 allocs, 293 frees, 222,596 bytes allocated
==32090==
==32090== LEAK SUMMARY:
==32090==definitely lost: 6,019 bytes in 36 blocks
==32090==indirectly lost: 82 bytes in 5 blocks
==32090==  possibly lost: 0 bytes in 0 blocks
==32090==still reachable: 165,678 bytes in 60 blocks
==32090== suppressed: 0 bytes in 0 blocks
==32090== Rerun with --leak-check=full to see details of leaked memory
==32090==
==32090== For counts of detected and suppressed errors, rerun with: -v
==32090== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Cheers,
Sourabh.

Re: Possible leaks observed in GCC.

2020-12-09 Thread Jonathan Wakely via Gcc 
On Wed, 9 Dec 2020 at 12:45, Tomar, Sourabh Singh via Gcc
 wrote:
>
> Hi Folks,
>
> I observed some leaks using valgrind while compiling a sample program using 
> GCC.

This seems more appropriate for gcc-h...@gcc.gnu.org instead.

> Could anyone aware of these details provide any insights to these leaks ?

You've provided no information that can tell us anything for sure, but
these are probably leaks caused by your code. You can use valgrind to
find them.

Valgrind tells you what to do:

> ==32090== Rerun with --leak-check=full to see details of leaked memory

Re: Possible leaks observed in GCC.

2020-12-09 Thread Paul Floyd 



On 12/9/20 1:44 PM, Tomar, Sourabh Singh via Gcc wrote:

Hi Folks,

I observed some leaks using valgrind while compiling a sample program using GCC.

Could anyone aware of these details provide any insights to these leaks ?

==32090== Rerun with --leak-check=full to see details of leaked memory



Hi

For a start, do what Valgrind told you to do (the line above that I kept).

I would also recommend --show-leak-kinds=all and -s.

A+

Paul

Re: Possible leaks observed in GCC.

2020-12-09 Thread Jonathan Wakely via Gcc 
On Wed, 9 Dec 2020 at 12:53, Jonathan Wakely  wrote:
>
> On Wed, 9 Dec 2020 at 12:45, Tomar, Sourabh Singh via Gcc
>  wrote:
> >
> > Hi Folks,
> >
> > I observed some leaks using valgrind while compiling a sample program using 
> > GCC.
>
> This seems more appropriate for gcc-h...@gcc.gnu.org instead.
>
> > Could anyone aware of these details provide any insights to these leaks ?
>
> You've provided no information that can tell us anything for sure, but
> these are probably leaks caused by your code. You can use valgrind to
> find them.

Oh sorry, I missed that you're running gcc itself under valgrind.
Those are probably intentional, because GCC uses garbage collection
for some of its allocations, and knows that it's not going to be a
long-running process, so it will exit fairly soon and all memory will
be freed on exit.

Using --leak-check=full would still give you more information.

Re: Possible leaks observed in GCC.

2020-12-09 Thread Jakub Jelinek via Gcc 
On Wed, Dec 09, 2020 at 12:55:40PM +, Jonathan Wakely via Gcc wrote:
> > > I observed some leaks using valgrind while compiling a sample program 
> > > using GCC.
> >
> > This seems more appropriate for gcc-h...@gcc.gnu.org instead.
> >
> > > Could anyone aware of these details provide any insights to these leaks ?
> >
> > You've provided no information that can tell us anything for sure, but
> > these are probably leaks caused by your code. You can use valgrind to
> > find them.
> 
> Oh sorry, I missed that you're running gcc itself under valgrind.
> Those are probably intentional, because GCC uses garbage collection
> for some of its allocations, and knows that it's not going to be a
> long-running process, so it will exit fairly soon and all memory will
> be freed on exit.
> 
> Using --leak-check=full would still give you more information.

Well, primarily it was run on the gcc driver rather than the actual
compiler, the only leaks in the driver would be somewhere in the option
handling and would be extremely low priority.  Leaks in the compiler are
much more interesting.
And second, without information which exact gcc version it is, there is
nothing that can be done about it anyway.

Jakub

Re: Possible leaks observed in GCC.

2020-12-09 Thread Paul Floyd 



On 12/9/20 1:44 PM, Tomar, Sourabh Singh via Gcc wrote:

Hi Folks,

I observed some leaks using valgrind while compiling a sample program using GCC.


==32090== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info


Also 3.13 is rather old. 3.16.1 is the current release - not that leak 
detection is exactly bleeding edge.



A+

Paul

Re: No warning for module global variable which is set but never used

2020-12-09 Thread webmaster 
I'm talking about C/C++ :-)
 Ursprüngliche Nachricht Von: Tobias Burnus 
 Datum: 09.12.20  13:15  (GMT+01:00) An: webmaster 
 Betreff: Re: No warning for module global variable 
which is set but never used The example below is for Fortran – but the same 
applies to C++ modulesand to static variable in general, especially if they are 
global variables.(It is not clear from the question about which language you 
were talking.)TobiasOn 09.12.20 13:13, Tobias Burnus wrote:> On 09.12.20 13:02, 
webmaster wrote:>>> Ahh, ok. With these explanation I understand that the 
compiler does>> remove it because of optimatizion. This is somehow good and 
bad.>> Good that unused variable does not consume any memory. Bad that>> 
developer is not informed that variable can be removed.>> That's the general 
problem with (module) global variables:>> module m>   integer :: A> end>> 
program main>   use m>   external foo>   A = 5>   call foo()> end>> 
> Now assume in a different file:>> subroutine foo> 
  use m>   print *, A> end>> In this case, the compiler cannot see while 
processing the first file> that 'foo' in a different file actually uses the 
variable - and cannot> warn.>> Doing tracking for static (implicit or explicit 
"SAVE") is difficult;> for (module) global variable it is impossible to do in 
general.>> Tobias>-Mentor Graphics (Deutschland) GmbH, 
Arnulfstraße 201, 80634 München / GermanyRegistergericht München HRB 106955, 
Geschäftsführer: Thomas Heurung, Alexander Walter

Re: No warning for module global variable which is set but never used

2020-12-09 Thread webmaster 
I have the following Code C\C++:

static int foo = 0;

static void bar(void)
{
foo = 1;
}

Here it is clear for the compiler that the variable foo can only be
accessed from the same modul and not from ther modules. From the
explanations before I understand that the variable is removed due to
optimization. But I do not understand why GCC does not throws a warning.

>From my point of view it is responsibility of the developer to remove
the unused variable.

Re: cacheflush.2

2020-12-09 Thread Alejandro Colomar (man-pages) via Gcc 
Hi Heinrich,

It looks like a bug (or at least an undocumented divergence from GCC) in
Clang/LLVM.  Or I couldn't find the documentation for it.

Clang uses 'char *':
https://github.com/llvm/llvm-project/blob/7faf62a80bfc3a9dfe34133681fcc31f8e8d658b/clang/include/clang/Basic/Builtins.def#L583

GCC uses 'void *':
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

I CCd Clang and GCC lists; maybe they know about that divergence.

Cheers,

Alex

On 12/9/20 7:48 PM, Heinrich Schuchardt wrote:
> On 12/9/20 7:34 PM, Alejandro Colomar (man-pages) wrote:
>> Hi Heinrich & Michael,
>>
>> What about the following?:
>>
>> [
>> NOTES
>>     GCC provides a similar function, which may be useful on  archi‐
>>     tectures that lack this system call:
>>
>>     void __builtin___clear_cache(void *begin, void *end);
>> ]
> 
> I just checked building with Clang/LLVM. There the arguments are of type
> (char *). See the following error output:
> 
> +arch/sandbox/cpu/cache.c:19:26: error: passing 'uint8_t *' (aka
> 'unsigned char *') to parameter of type 'char *' converts between
> pointers to integer types with different sign [-Werror,-Wpointer-sign]
> +    __builtin___clear_cache(state->ram_buf,
> +    ^~
> +arch/sandbox/cpu/cache.c:20:12: error: passing 'uint8_t *' (aka
> 'unsigned char *') to parameter of type 'char *' converts between
> pointers to integer types with different sign [-Werror,-Wpointer-sign]
> +    state->ram_buf + state->ram_size);
> +    ^~~~
> 
> Best regards
> 
> Heinrich
> 
>>
>> Cheers,
>>
>> Alex
>>
>> On 12/9/20 7:04 PM, Heinrich Schuchardt wrote:
>>> Hello Michael,
>>>
>>> function cacheflush() does not exist on many architectures.
>>>
>>> It would have saved me a lot of time if the man-page had referenced
>>> GCC's
>>>
>>> void __builtin___clear_cache(void *begin, void *end)
>>>
>>> Maybe you can add it to NOTES.
>>>
>>> Best regards
>>>
>>> heirnich
>>
> 

-- 
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es

Move STV(scalars_to_vector) RTL pass from i386 to target independent

2020-12-09 Thread Dinar Temirbulatov via Gcc 
Hi,
I have observed that STV2 pass added ~20% on CPU2006 456.hmmer with mostly
by transforming V4SI operations. Looking at the pass itself, it looks like
it might be transformed into RTL architecture-independent, and the pass
deals only not wide integer operations. I think it might be useful on other
targets as well?
   Thanks, Dinar.

Re: Help with PR97872

2020-12-09 Thread Hongtao Liu via Gcc 
It seems better with your PR97872 fix on i386.

Cat test.c

typedef char v16qi __attribute__ ((vector_size(16)));
v16qi f1(v16qi a, v16qi b) {
return (a & b) != 0;
}

before

f1(char __vector(16), char __vector(16)):
pand %xmm1, %xmm0
pxor %xmm1, %xmm1
pcmpeqb %xmm1, %xmm0
pcmpeqd %xmm1, %xmm1
pandn %xmm1, %xmm0
ret

After the pr97872 fix

f1(char __vector(16), char __vector(16)):
pand xmm0, xmm1
pxor xmm1, xmm1
pcmpeqb xmm0, xmm1
pcmpeqb xmm0, xmm1
ret

On Wed, Dec 9, 2020 at 7:47 PM Prathamesh Kulkarni
 wrote:
>
> On Tue, 8 Dec 2020 at 14:36, Prathamesh Kulkarni
>  wrote:
> >
> > On Mon, 7 Dec 2020 at 17:37, Hongtao Liu  wrote:
> > >
> > > On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
> > >  wrote:
> > > >
> > > > On Mon, 7 Dec 2020 at 16:15, Hongtao Liu  wrote:
> > > > >
> > > > > On Mon, Dec 7, 2020 at 5:47 PM Richard Biener  
> > > > > wrote:
> > > > > >
> > > > > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > >
> > > > > > > On Mon, 7 Dec 2020 at 13:01, Richard Biener  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > > > >
> > > > > > > > > On Fri, 4 Dec 2020 at 17:18, Richard Biener 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, 4 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > > > > > >
> > > > > > > > > > > On Thu, 3 Dec 2020 at 16:35, Richard Biener 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, 3 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, 1 Dec 2020 at 16:39, Richard Biener 
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, 1 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > For the test mentioned in PR, I was trying to see 
> > > > > > > > > > > > > > > if we could do
> > > > > > > > > > > > > > > specialized expansion for vcond in target when 
> > > > > > > > > > > > > > > operands are -1 and 0.
> > > > > > > > > > > > > > > arm_expand_vcond gets the following operands:
> > > > > > > > > > > > > > > (reg:V8QI 113 [ _2 ])
> > > > > > > > > > > > > > > (reg:V8QI 117)
> > > > > > > > > > > > > > > (reg:V8QI 118)
> > > > > > > > > > > > > > > (lt (reg/v:V8QI 115 [ a ])
> > > > > > > > > > > > > > > (reg/v:V8QI 116 [ b ]))
> > > > > > > > > > > > > > > (reg/v:V8QI 115 [ a ])
> > > > > > > > > > > > > > > (reg/v:V8QI 116 [ b ])
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > where r117 and r118 are set to vector constants 
> > > > > > > > > > > > > > > -1 and 0 respectively.
> > > > > > > > > > > > > > > However, I am not sure if there's a way to check 
> > > > > > > > > > > > > > > if the register is
> > > > > > > > > > > > > > > constant during expansion time (since we don't 
> > > > > > > > > > > > > > > have df analysis yet) ?
> > > > >
> > > > > It seems to me that all you need to do is relax the predicates of op1
> > > > > and op2 in vcondmn to accept const0_rtx and constm1_rtx. I haven't
> > > > > debugged it, but I see that vcondmn in neon.md only accepts
> > > > > s_register_operand.
> > > > >
> > > > > (define_expand "vcond"
> > > > >   [(set (match_operand:VDQW 0 "s_register_operand")
> > > > > (if_then_else:VDQW
> > > > >   (match_operator 3 "comparison_operator"
> > > > > [(match_operand:VDQW 4 "s_register_operand")
> > > > >  (match_operand:VDQW 5 "reg_or_zero_operand")])
> > > > >   (match_operand:VDQW 1 "s_register_operand")
> > > > >   (match_operand:VDQW 2 "s_register_operand")))]
> > > > >   "TARGET_NEON && (! || 
> > > > > flag_unsafe_math_optimizations)"
> > > > > {
> > > > >   arm_expand_vcond (operands, mode);
> > > > >   DONE;
> > > > > })
> > > > >
> > > > > in sse.md it's defined as
> > > > > (define_expand "vcondu"
> > > > >   [(set (match_operand:V_512 0 "register_operand")
> > > > > (if_then_else:V_512
> > > > >   (match_operator 3 ""
> > > > > [(match_operand:VI_AVX512BW 4 "nonimmediate_operand")
> > > > >  (match_operand:VI_AVX512BW 5 "nonimmediate_operand")])
> > > > >   (match_operand:V_512 1 "general_operand")
> > > > >   (match_operand:V_512 2 "general_operand")))]
> > > > >   "TARGET_AVX512F
> > > > >&& (GET_MODE_NUNITS (mode)
> > > > >== GET_MODE_NUNITS (mode))"
> > > > > {
> > > > >   bool ok = ix86_expand_int_vcond (operands);
> > > > >   gcc_assert (ok);
> > > > >   DONE;
> > > > > })
> > > > >
> > > > > then we can get operands[1] and operands[2] as
> > > > >
> > > > > (gdb) p debug_rtx (operands[1])
> > > > >  (const_vector:V16QI [
> > > > > (const_int -1 [0x]) repeated x16
> > > > > ])
> > > > > (gdb) p debug_rtx (operands[2])
> > > > > (reg:V16QI 82 [ _2 ])
> > > > > (const_vector:V16QI [
> > > > > (const_int 0 [0]) repeated x16
> > > > > ])
> > > > Hi Hongtao,

Voicemail To Email

2020-12-09 Thread BuBleik SAL via Gcc 

BuBleik SAL
Virtual Office & Virtual Assistant





Working from home and you don't want to miss a call. We got you covered.


The Voicemail To Email subscription with BuBleik SAL, offers you the luxury to 
have a city land line telephone number, answered by an automated welcome 
message of your choice and once your caller leaves you a message, you will 
immediately receive in your inbox by email, and on 24/7 bases. 


No worries sharing your home telephone line with your business accounts.




+961 1 411 222
sa...@bubleik.com








SUBSCRIBE NOW[Ads961.com] Professional Advertisement in Lebanon(email) 

b...@adsleb.com (Tel) 

+961 1 411 410 (whatsapp) 

+961 71 072 786If you no longer wish to receive mail from us, you can   
 

unsubscribe

Ads961, Badaro, Beirut, LB, 50-110, Lebanon