Snake Trap

[EPS Environmental via Gcc]

Snake Trap

catches all snakes, rodents and crowling insects (including poisonous snakes)
20,000 LBP per unit (up to 5 traps with installation) - suitable for Homes
16,000 LBP per unit (up to 20 traps with installation and weekly visit) - 
suitable for Bakeries, Pastries, Retaurants or Hotels


Gabriel Mitri
Managing Director 
EPS ENVIRONMEMTAL Ets.
Green motion  "We Convert Waste Into Money"
Mobile     : +961 76 911 483
Skype ID   : Gabriel Mitri LB 
E-mail     : eps.gm.mi...@gmail.com

[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

Do all global structure variables escape in IPA-PTA?

[Erick Ochoa]

Hi,

I'm trying to understand how the escape analysis in IPA-PTA works. I was 
testing a hypothesis where if a structure contains an array of 
characters and this array of characters is passed to fopen, the 
structure and all subfields will escape.


To do this, I made a program that has a global structure variable foo2 
that is has a field passed as an argument to fopen. I also made another 
variable foo whose array is initialized by the result of rand.


However, after compiling this program with -flto -flto-partition=none 
-fipa -fdump-ipa-pta -fdump-tree-all-all -Ofast (gcc --version 10.2.0)


E.g.

#include 
#include 
#include 

struct foo_t {
  char buffer1[100];
  char buffer2[100];
};

struct foo_t foo;
struct foo_t foo2;

int
main(int argc, char** argv)
{

  fopen(foo2.buffer1, "r");
  for (int i = 0; i < 100; i++)
  {
foo.buffer1[i] = rand();
  }
  int i = rand();
  int retval = foo.buffer1[i % 100];
  return retval;
}

I see the PTA dump state the following:

ESCAPED = { STRING ESCAPED NONLOCAL foo2 }
foo = { ESCAPED NONLOCAL }
foo2 = { ESCAPED NONLOCAL }

which I understand as
* something externally visible might point to foo2
* foo2 might point to something externally visible
* foo might point to something externally visible

I have seen that global variables are stored in the .gnu.lto_.decls LTO 
file section. In the passes I have worked on I have ignored global 
variables. But can foo and foo2 be marked as escaping because the 
declarations are not streamed in yet? Or is there another reason I am 
not seeing? I am aware of aware of the several TODOs at the beginning of 
gcc/tree-ssa-structalias.c but I am unsure if they contribute to these 
variables being marked as escaping. (Maybe TODO 1 and TODO 2?)


Just FYI, I've been reading:
* Structure Aliasing in GCC
* Gimple Alias Improvements for GCC 4.5
* Memory SSA - A Unified Approach for Sparsely Representing Memory 
Operations


Thanks, I appreciate all help!

Re: Do all global structure variables escape in IPA-PTA?

[Richard Biener via Gcc]

On August 25, 2020 3:09:13 PM GMT+02:00, Erick Ochoa 
 wrote:
>Hi,
>
>I'm trying to understand how the escape analysis in IPA-PTA works. I
>was 
>testing a hypothesis where if a structure contains an array of 
>characters and this array of characters is passed to fopen, the 
>structure and all subfields will escape.
>
>To do this, I made a program that has a global structure variable foo2 
>that is has a field passed as an argument to fopen. I also made another
>
>variable foo whose array is initialized by the result of rand.
>
>However, after compiling this program with -flto -flto-partition=none 
>-fipa -fdump-ipa-pta -fdump-tree-all-all -Ofast (gcc --version 10.2.0)
>
>E.g.
>
>#include 
>#include 
>#include 
>
>struct foo_t {
>   char buffer1[100];
>   char buffer2[100];
>};
>
>struct foo_t foo;
>struct foo_t foo2;
>
>int
>main(int argc, char** argv)
>{
>
>   fopen(foo2.buffer1, "r");
>   for (int i = 0; i < 100; i++)
>   {
> foo.buffer1[i] = rand();
>   }
>   int i = rand();
>   int retval = foo.buffer1[i % 100];
>   return retval;
>}
>
>I see the PTA dump state the following:
>
>ESCAPED = { STRING ESCAPED NONLOCAL foo2 }
>foo = { ESCAPED NONLOCAL }
>foo2 = { ESCAPED NONLOCAL }
>
>which I understand as
>* something externally visible might point to foo2
>* foo2 might point to something externally visible
>* foo might point to something externally visible

Yes. So it's exactly as your hypothesis. 

>I have seen that global variables are stored in the .gnu.lto_.decls LTO
>
>file section. In the passes I have worked on I have ignored global 
>variables. But can foo and foo2 be marked as escaping because the 
>declarations are not streamed in yet? Or is there another reason I am 
>not seeing? I am aware of aware of the several TODOs at the beginning
>of 
>gcc/tree-ssa-structalias.c but I am unsure if they contribute to these 
>variables being marked as escaping. (Maybe TODO 1 and TODO 2?)

Not sure what the problem is. Foo2 escapes because it's address is passed to a 
function. 

? 

Richard. 

>Just FYI, I've been reading:
>* Structure Aliasing in GCC
>* Gimple Alias Improvements for GCC 4.5
>* Memory SSA - A Unified Approach for Sparsely Representing Memory 
>Operations
>
>Thanks, I appreciate all help!

Re: Question about IPA-PTA and build_alias

[Richard Biener via Gcc]

On August 24, 2020 10:00:44 AM GMT+02:00, Erick Ochoa 
 wrote:
>
>
>On 24/08/2020 09:40, Richard Biener wrote:
>> On Mon, Aug 17, 2020 at 3:22 PM Erick Ochoa
>>  wrote:
>>>
>>> Hello,
>>>
>>> I'm looking to understand better the points-to analysis (IPA-PTA)
>and
>>> the alias analysis (build_alias).
>>>
>>> How is the information produced by IPA-PTA consumed?
>>>
>>> Are alias sets in build_alias computed by the intersections of the
>>> points_to_set(s) (computed by IPA-PTA)?
>>>
>>> My intuition tells me that it could be relatively simple to move
>>> build_alias to be an SIMPLE_IPA_PASS performed just after IPA-PTA,
>but I
>>> do not have enough experience in GCC to tell if this is correct.
>What
>>> could be some difficulties which I am not seeing? (Either move, or
>>> create a new IPA-ALIAS SIMPLE_IPA_PASS.) This pass would have the
>same
>>> sensitivity as IPA-PTA { flow-insensitive, context-insensitive,
>>> field-sensitive } because the alias sets could be computed by the
>>> intersection of points-to-sets.
>> 
>> Both IPA-PTA and build_alias do the same, they build PTA constraint
>> sets, solve them and attach points-to info to SSA names.  Just
>IPA-PTA
>> does this for the whole TU while build_alias does it for a function
>at a time.
>> 
>> So I guess I do not understand your question.
>
>Hi Richard,
>
>I'm just trying to imagine what a data-layout optimization would look 
>like if instead of using the type-escape analysis we used the points-to
>
>analysis to find out which variables/memory locations escape and what 
>that would mean for the transformation itself.

What I've said before is that for the object based approach you need precise 
following of pointers which covers escape analysis already. For non allocated 
objects you need to find possible address taken and accesses. 

I don't think the escape analysis included in IPA points-to analysis will help 
you in the end. The constraint solver does not do the precise analysis you need 
as well but the precise analysis will give you conservative escape results. 

>One of the things that I think would be needed are alias-sets. I
>thought 
>that build_alias was building alias sets but I was mistaken. However, 
>computing the alias sets should not be too difficult.
>
>Also continuing imagining what a data-layout optimization would look 
>like in GCC, since IPA-PTA is a SIMPLE_IPA_PASS and if alias sets are 
>indeed needed, I was asking what would be the reception to a 
>SIMPLE_IPA_PASS that computes alias sets just after IPA-PTA. (As
>opposed 
>to a full ipa pass).

If you look we skip simple analysis if IPA analysis was done to not overwrite 
its results. So forcing it (even earlier) would make IPA analysis moot which 
would of course not be welcome. 

Richard. 

>
>
>
>> 
>> Richard.
>> 
>>>
>>> Thanks!

Re: Do all global structure variables escape in IPA-PTA?

[Erick Ochoa]

On 25/08/2020 17:10, Richard Biener wrote:

On August 25, 2020 3:09:13 PM GMT+02:00, Erick Ochoa 
 wrote:

Hi,

I'm trying to understand how the escape analysis in IPA-PTA works. I
was
testing a hypothesis where if a structure contains an array of
characters and this array of characters is passed to fopen, the
structure and all subfields will escape.

To do this, I made a program that has a global structure variable foo2
that is has a field passed as an argument to fopen. I also made another

variable foo whose array is initialized by the result of rand.

However, after compiling this program with -flto -flto-partition=none
-fipa -fdump-ipa-pta -fdump-tree-all-all -Ofast (gcc --version 10.2.0)

E.g.

#include 
#include 
#include 

struct foo_t {
   char buffer1[100];
   char buffer2[100];
};

struct foo_t foo;
struct foo_t foo2;

int
main(int argc, char** argv)
{

   fopen(foo2.buffer1, "r");
   for (int i = 0; i < 100; i++)
   {
 foo.buffer1[i] = rand();
   }
   int i = rand();
   int retval = foo.buffer1[i % 100];
   return retval;
}

I see the PTA dump state the following:

ESCAPED = { STRING ESCAPED NONLOCAL foo2 }
foo = { ESCAPED NONLOCAL }
foo2 = { ESCAPED NONLOCAL }

which I understand as
* something externally visible might point to foo2
* foo2 might point to something externally visible
* foo might point to something externally visible


Yes. So it's exactly as your hypothesis.


I have seen that global variables are stored in the .gnu.lto_.decls LTO

file section. In the passes I have worked on I have ignored global
variables. But can foo and foo2 be marked as escaping because the
declarations are not streamed in yet? Or is there another reason I am
not seeing? I am aware of aware of the several TODOs at the beginning
of
gcc/tree-ssa-structalias.c but I am unsure if they contribute to these
variables being marked as escaping. (Maybe TODO 1 and TODO 2?)


Not sure what the problem is. Foo2 escapes because it's address is passed to a 
function.



foo2 is not the problem, it is foo. foo is not passed to a function and 
it is also escaping.



?

Richard.


Just FYI, I've been reading:
* Structure Aliasing in GCC
* Gimple Alias Improvements for GCC 4.5
* Memory SSA - A Unified Approach for Sparsely Representing Memory
Operations

Thanks, I appreciate all help!

Re: Do all global structure variables escape in IPA-PTA?

[Erick Ochoa]

On 25/08/2020 17:19, Erick Ochoa wrote:



On 25/08/2020 17:10, Richard Biener wrote:
On August 25, 2020 3:09:13 PM GMT+02:00, Erick Ochoa 
 wrote:

Hi,

I'm trying to understand how the escape analysis in IPA-PTA works. I
was
testing a hypothesis where if a structure contains an array of
characters and this array of characters is passed to fopen, the
structure and all subfields will escape.

To do this, I made a program that has a global structure variable foo2
that is has a field passed as an argument to fopen. I also made another

variable foo whose array is initialized by the result of rand.

However, after compiling this program with -flto -flto-partition=none
-fipa -fdump-ipa-pta -fdump-tree-all-all -Ofast (gcc --version 10.2.0)

E.g.

#include 
#include 
#include 

struct foo_t {
   char buffer1[100];
   char buffer2[100];
};

struct foo_t foo;
struct foo_t foo2;

int
main(int argc, char** argv)
{

   fopen(foo2.buffer1, "r");
   for (int i = 0; i < 100; i++)
   {
 foo.buffer1[i] = rand();
   }
   int i = rand();
   int retval = foo.buffer1[i % 100];
   return retval;
}

I see the PTA dump state the following:

ESCAPED = { STRING ESCAPED NONLOCAL foo2 }
foo = { ESCAPED NONLOCAL }
foo2 = { ESCAPED NONLOCAL }

which I understand as
* something externally visible might point to foo2
* foo2 might point to something externally visible
* foo might point to something externally visible


Yes. So it's exactly as your hypothesis.


I have seen that global variables are stored in the .gnu.lto_.decls LTO

file section. In the passes I have worked on I have ignored global
variables. But can foo and foo2 be marked as escaping because the
declarations are not streamed in yet? Or is there another reason I am
not seeing? I am aware of aware of the several TODOs at the beginning
of
gcc/tree-ssa-structalias.c but I am unsure if they contribute to these
variables being marked as escaping. (Maybe TODO 1 and TODO 2?)


Not sure what the problem is. Foo2 escapes because it's address is 
passed to a function.




foo2 is not the problem, it is foo. foo is not passed to a function and 
it is also escaping.



Sorry, I meant: foo might point to something which is externally 
visible. Which I don't think is the case in the program. I understand 
this might be due to the imprecision in the escape-analysis and what I'm 
trying to find out is the source of imprecision.





?

Richard.


Just FYI, I've been reading:
* Structure Aliasing in GCC
* Gimple Alias Improvements for GCC 4.5
* Memory SSA - A Unified Approach for Sparsely Representing Memory
Operations

Thanks, I appreciate all help!

Re: Do all global structure variables escape in IPA-PTA?

[Richard Biener via Gcc]

On August 25, 2020 6:36:19 PM GMT+02:00, Erick Ochoa 
 wrote:
>
>
>On 25/08/2020 17:19, Erick Ochoa wrote:
>> 
>> 
>> On 25/08/2020 17:10, Richard Biener wrote:
>>> On August 25, 2020 3:09:13 PM GMT+02:00, Erick Ochoa 
>>>  wrote:
 Hi,

 I'm trying to understand how the escape analysis in IPA-PTA works.
>I
 was
 testing a hypothesis where if a structure contains an array of
 characters and this array of characters is passed to fopen, the
 structure and all subfields will escape.

 To do this, I made a program that has a global structure variable
>foo2
 that is has a field passed as an argument to fopen. I also made
>another

 variable foo whose array is initialized by the result of rand.

 However, after compiling this program with -flto
>-flto-partition=none
 -fipa -fdump-ipa-pta -fdump-tree-all-all -Ofast (gcc --version
>10.2.0)

 E.g.

 #include 
 #include 
 #include 

 struct foo_t {
    char buffer1[100];
    char buffer2[100];
 };

 struct foo_t foo;
 struct foo_t foo2;

 int
 main(int argc, char** argv)
 {

    fopen(foo2.buffer1, "r");
    for (int i = 0; i < 100; i++)
    {
  foo.buffer1[i] = rand();
    }
    int i = rand();
    int retval = foo.buffer1[i % 100];
    return retval;
 }

 I see the PTA dump state the following:

 ESCAPED = { STRING ESCAPED NONLOCAL foo2 }
 foo = { ESCAPED NONLOCAL }
 foo2 = { ESCAPED NONLOCAL }

 which I understand as
 * something externally visible might point to foo2
 * foo2 might point to something externally visible
 * foo might point to something externally visible
>>>
>>> Yes. So it's exactly as your hypothesis.
>>>
 I have seen that global variables are stored in the .gnu.lto_.decls
>LTO

 file section. In the passes I have worked on I have ignored global
 variables. But can foo and foo2 be marked as escaping because the
 declarations are not streamed in yet? Or is there another reason I
>am
 not seeing? I am aware of aware of the several TODOs at the
>beginning
 of
 gcc/tree-ssa-structalias.c but I am unsure if they contribute to
>these
 variables being marked as escaping. (Maybe TODO 1 and TODO 2?)
>>>
>>> Not sure what the problem is. Foo2 escapes because it's address is 
>>> passed to a function.
>>>
>> 
>> foo2 is not the problem, it is foo. foo is not passed to a function
>and 
>> it is also escaping.
>
>
>Sorry, I meant: foo might point to something which is externally 
>visible. Which I don't think is the case in the program. I understand 
>this might be due to the imprecision in the escape-analysis and what
>I'm 
>trying to find out is the source of imprecision.

Foo is exported and thus all function calls can store to it making it point to 
escaped and nonlocal variables. 

Richard. 

>> 
>>> ?
>>>
>>> Richard.
>>>
 Just FYI, I've been reading:
 * Structure Aliasing in GCC
 * Gimple Alias Improvements for GCC 4.5
 * Memory SSA - A Unified Approach for Sparsely Representing Memory
 Operations

 Thanks, I appreciate all help!
>>>

Re: Does -fstack-protector really need to clear registers?

[Jeff Law via Gcc]

On Wed, 2020-08-05 at 18:12 +0100, Richard Sandiford wrote:
> PR96191 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191]
> was a bug raised against the aarch64 implementation of -fstack-protector.
> As it happens, the same bug affected arm, but AFAICT those are the only
> two affected targets.
> 
> -fstack-protector works by:
> 
> * creating a special canary slot in the stack frame,
> * initialising it with a special canary value, and then
> * checking at the end of the function whether the canary slot still has
>   the correct value.
> 
> If the slot has changed value, the function calls a special stack-smash
> handler that would typically abort the program.
> 
> On many targets, the code that sets up and tests the canary slot will
> need to load the canary value into registers.  However, GCC tries
> to guarantee that this value does not remain in registers beyond the
> “test” and “set” operations.  For example, the documentation of the
> stack_protect_test pattern says:
> 
>   This pattern, if defined, compares a @code{ptr_mode} value from the
>   valid memory location in operand 1 with the memory in operand 0 without
>   leaving the value in a register afterward and branches to operand 2 if
>   the values were equal.
> 
>   If this pattern is not defined, then a plain compare pattern and
>   conditional branch pattern is used.
> 
> The bug in the PR was that aarch64 (and arm) did this when setting up
> the canary slot, but not when testing it.
> 
> However, it's not obvious (to me) whether this is really necessary and
> what it's really protecting against.  Even if we zero out the registers
> after these patterns, the canary value is still readily available by
> other means:
I suspect folks were just being paranoid and trying to do the right thing. The
fact there's other way to get at the data doesn't necessarily mean we should
leave it lying around in a convenient register.


> 
> (1) We don't make any effort to hide the address of the canary value
> (typically &__stack_chk_guard, although some targets support
> alternatives).  It's not obvious what “hiding” this address
> would actually mean in practice, since it would often be easily
> predictable from other non-secret addresses.
Well, isn't that only when the target doesn't support storing the guard in 
thread
local storage??   ie, I don't think you can get it consistently this way.

Now the pointer guard is a completely different story and I've been trying to 
get
that fixed for years ;(  Though I must admit it was awful nice to have it
available in a global when I needed to debug a problem related to pointer
mangling in glibc...



> 
> (2) The canary value is often available in stack locations, such as:
> 
> (a) a canary in the current function, if the current function
> uses stack-smash protection
> 
> (b) a “protected” caller further up the call stack
> 
> (c) canary values left around by previous calls, if the canary value
> happens to occupy “dead space” in the current frame
> 
> And being on the stack is of course fundamental to the whole scheme.
Yea, but these you have to go and find ;-)

> 

Jeff

Re: Peephole optimisation: isWhitespace()

[Stefan Kanthak]

I wrote:

> "Richard Biener"  wrote:

[...]
 
>> Whether or not the branch is predicted taken does not matter, what
>> matters is that the continuation is not data dependent on the branch
>> target computation and thus can execute in parallel to it.
> 
> My benchmark shows that this doesn't matter!

>>> I already presented measured numbers: with random data, the branch-free
>>> code is faster, with ordered data the original code.

[...]

>> We do know that mispredicted branches are bad.
>> You show well-predicted branches are good.
> 
> Wrong: I show that no branches are still better.
> 
>> By simple statistics singling out 4 out of 255 values will make the
>> branches well-predicted.
> 
> Your statistic is wrong:
> 1. the branch singles out 224 of 256 values, i.e. 7/8 of all data;
> 2. whitespace lies in the 1/8 which is not singled out.
> 
>>> Now perform a linear interpolation and find the break-even point at
>>> p=0.4, with p=0 for ordered data and p=1 for random data, or just use
>>> the average of these numbers: 2.9 cycles vs. 2.75 cycles.
>>> That's small, but measurable!

I recommend you ALL start to read Daniel Lemire's article


| Even when it is impossible to remove all branches, reducing the number
| of branches "almost always taken" or "almost never taken" may help the
| processor better predict the remaining branches.

JFTR: I didn't know his article before, but I hope that you are willing
  to learn.

Stefan

Re: Clobber REG_CC only for some constraint alternatives?

[Hans-Peter Nilsson]

On Mon, 24 Aug 2020, Jeff Law via Gcc wrote:
> On Thu, 2020-08-20 at 21:36 +0530, Senthil Kumar Selvaraj via Gcc wrote:
> > The post-reload splitter introduces the clobber. The wiki
> > suggests that approach if most insns clobber REG_CC, perhaps because of
> > the missed optimizations you describe below?
> If most patterns set/clobber the flags, then yes, it's slightly better to only
> expose them after reload.   Various passes that directly grub through RTL 
> rather
> than using helpers like single_set will optimize things better.

The "slightly" being omissions like the one fixed in combine.c
last month. ;-)  There's one in reload too ("Discard obvious
no-ops, even without -O"), but it seems to be acting the other
way(!)

If, for a machine where most insns clobber REG_CC, you instead
emit with the clobber initially, you can have a tidier port: one
define_subst:ed pattern instead of...  How many is it with the
only-expose-after-reload method (counting define_insn,
define_split, possibly a define_expand too that wasn't there for
cc0)?  Two or three, per (original) insn with cc0?

brgds, H-P