in search of clue regarding -fcheck-memory-usage

in search of clue regarding -fcheck-memory-usage

[Zack Weinberg]

So I'm trying to fix the fixup_var_refs bottleneck, which looks like
it will take some pretty drastic changes to function.c and related,
and I can't figure out what to do with the -fcheck-memory-usage hooks.

Here's a sample:

  if (current_function_check_memory_usage)
    emit_library_call (chkr_set_right_libfunc, LCT_CONST_MAKE_BLOCK, VOIDmode,
		       3, XEXP (reg, 0), Pmode,
		       GEN_INT (GET_MODE_SIZE (GET_MODE (reg))),
		       TYPE_MODE (sizetype),
		       GEN_INT (MEMORY_USE_RW),
		       TYPE_MODE (integer_type_node));

So this generates a call to a runtime library routine.  It's being
handed a bunch of data regarding a variable that we just decided had
to live in a stack slot.  Beyond that I don't know what it does.

My major concern is that up till now 'reg' had been destructively
replaced by a MEM rtx before we got here.  My changes are going to
postpone that until after we're done generating RTL.  So XEXP (reg, 0)
is now an invalid operation.  What should I be replacing it with?

zw

Re: in search of clue regarding -fcheck-memory-usage

[Mark Mitchell]

>>>>> "Zack" == Zack Weinberg <zackw@stanford.edu> writes:

    Zack> My major concern is that up till now 'reg' had been
    Zack> destructively replaced by a MEM rtx before we got here.  My
    Zack> changes are going to postpone that until after we're done
    Zack> generating RTL.  So XEXP (reg, 0) is now an invalid
    Zack> operation.  What should I be replacing it with?

An ADDRESSOF?  Isn't what the thing wants in the end -- the address of
some memory?  So, you can use ADDRESSOF (REG), and then rely on the
ADDRESSOF pass to insert this stuff later.

This is part of why I objected to the design of the -fcheck-memory
stuff; it is too interleaved with ordinary compiler processing.  It
should be a separate pass -- either on trees or RTL.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: in search of clue regarding -fcheck-memory-usage

[Zack Weinberg]

On Sun, Jan 21, 2001 at 12:38:32PM -0800, Mark Mitchell wrote:
> >>>>> "Zack" == Zack Weinberg <zackw@stanford.edu> writes:
> 
>     Zack> My major concern is that up till now 'reg' had been
>     Zack> destructively replaced by a MEM rtx before we got here.  My
>     Zack> changes are going to postpone that until after we're done
>     Zack> generating RTL.  So XEXP (reg, 0) is now an invalid
>     Zack> operation.  What should I be replacing it with?
> 
> An ADDRESSOF?  Isn't what the thing wants in the end -- the address of
> some memory?  So, you can use ADDRESSOF (REG), and then rely on the
> ADDRESSOF pass to insert this stuff later.

This is happening in put_var_into_stack, which is just when we do
generate ADDRESSOFs (sometimes).  However, even if we do do that, the
new RTL wasn't visible once I stopped clobbering the original REG.

I worked out a way to deal with it, hopefully.

> This is part of why I objected to the design of the -fcheck-memory
> stuff; it is too interleaved with ordinary compiler processing.  It
> should be a separate pass -- either on trees or RTL.

It doesn't help that the library functions it's calling are not part
of the GCC runtime...

zw

Re: in search of clue regarding -fcheck-memory-usage

[Tristan Gingold]

On Sun, Jan 21, 2001 at 12:38:32PM -0800, Mark Mitchell wrote:
> >>>>> "Zack" == Zack Weinberg <zackw@stanford.edu> writes:
> 
>     Zack> My major concern is that up till now 'reg' had been
>     Zack> destructively replaced by a MEM rtx before we got here.  My
>     Zack> changes are going to postpone that until after we're done
>     Zack> generating RTL.  So XEXP (reg, 0) is now an invalid
>     Zack> operation.  What should I be replacing it with?
> 
> An ADDRESSOF?  Isn't what the thing wants in the end -- the address of
> some memory?  So, you can use ADDRESSOF (REG), and then rely on the
> ADDRESSOF pass to insert this stuff later.
> 
> This is part of why I objected to the design of the -fcheck-memory
> stuff; it is too interleaved with ordinary compiler processing.  It
> should be a separate pass -- either on trees or RTL.
Being at the origin of the -fcheck-memory patches, I agree with you: it is too
interleaved.  I think a separate pass on tree is the right way to do the job
(RTL is really too late), but is there a single point of entry ?

If it is possible to do this pass, I am ready to write it.

Tristan.

Re: in search of clue regarding -fcheck-memory-usage

[Mark Mitchell]

>>>>> "Tristan" == Tristan Gingold <tgi@netgem.com> writes:

    Tristan> Being at the origin of the -fcheck-memory patches, I
    Tristan> agree with you: it is too interleaved.  I think a

Cool!  That's nice of you to say.

    Tristan> separate pass on tree is the right way to do the job (RTL
    Tristan> is really too late), but is there a single point of entry
    Tristan> ?

There is in C and C++ now.  Look, for example, at cp/optimize.c to see
how inlining is done entirely on trees.  You could do a similar pass
to add memory checking calls.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: in search of clue regarding -fcheck-memory-usage

[Joseph S. Myers]

On Mon, 22 Jan 2001, Tristan Gingold wrote:

> Being at the origin of the -fcheck-memory patches, I agree with you: it is too

Perhaps you can then answer the following (which I asked of
bug-checker@gnu.org in November, but didn't get any replies from there):
is Checker currently maintained; will there be a version that works with
GCC 3.0?

If not, the documentation for -fcheck-memory-usage should make this clear:
that the support is bitrotten.

From my previous message: the supposition of problems (with current GCC)
comes from:

* The Checker web site ( http://www.gnu.org/software/checker/checker.html )
says gcc 2.8.1 is required, and points to alpha.gnu.org for the current
Checker version.  The most recent version there, 0.9.9.1, is two years
old, and includes patches against gcc 2.8.1 and egcs 19980803.

* There have been problems reports such as
<URL: http://gcc.gnu.org/ml/gcc/2000-09/msg00352.html >.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: in search of clue regarding -fcheck-memory-usage

[Joe Buck]

> >From my previous message: the supposition of problems (with current GCC)
> comes from:
> 
> * The Checker web site ( http://www.gnu.org/software/checker/checker.html )
> says gcc 2.8.1 is required, and points to alpha.gnu.org for the current
> Checker version.  The most recent version there, 0.9.9.1, is two years
> old, and includes patches against gcc 2.8.1 and egcs 19980803.

The Debian folks seem to be shipping a C-only Checker that allegedly works
with 2.95.2.  I know very little about this though.

Re: in search of clue regarding -fcheck-memory-usage

[Tristan Gingold]

On Mon, Jan 22, 2001 at 06:47:51PM +0000, Joseph S. Myers wrote:
> On Mon, 22 Jan 2001, Tristan Gingold wrote:
> 
> > Being at the origin of the -fcheck-memory patches, I agree with you: it is too
> 
> Perhaps you can then answer the following (which I asked of
> bug-checker@gnu.org in November, but didn't get any replies from there):
> is Checker currently maintained; will there be a version that works with
> GCC 3.0?
Checker is not actively maintained.  However, it was updated in the snapshot
for gcc 2.95.2

> If not, the documentation for -fcheck-memory-usage should make this clear:
> that the support is bitrotten.
I think this option is like -finstrument-functions: it adds hooks, you can
do what you want with them.

> >From my previous message: the supposition of problems (with current GCC)
> comes from:
> 
> * The Checker web site ( http://www.gnu.org/software/checker/checker.html )
> says gcc 2.8.1 is required, and points to alpha.gnu.org for the current
> Checker version.  The most recent version there, 0.9.9.1, is two years
> old, and includes patches against gcc 2.8.1 and egcs 19980803.
> 
> * There have been problems reports such as
> <URL: http://gcc.gnu.org/ml/gcc/2000-09/msg00352.html >.
Tristan.

You can get the latest snapshot, via anonymous cvs:
> cvs -d :pserver:anoncvs@subversions.gnu.org:/cvs login
Password: [just hit enter]
> cvs -d :pserver:anoncvs@subversions.gnu.org:/cvs checkout checker
See http://www.gnu.org/software/devel.html#CVS for more information.
You might need to build configure file with autoconf

Re: in search of clue regarding -fcheck-memory-usage

[Tristan Gingold]

On Mon, Jan 22, 2001 at 10:31:56AM -0800, Mark Mitchell wrote:
> >>>>> "Tristan" == Tristan Gingold <tgi@netgem.com> writes:
> 
>     Tristan> Being at the origin of the -fcheck-memory patches, I
>     Tristan> agree with you: it is too interleaved.  I think a
> 
> Cool!  That's nice of you to say.
> 
>     Tristan> separate pass on tree is the right way to do the job (RTL
>     Tristan> is really too late), but is there a single point of entry
>     Tristan> ?
> 
> There is in C and C++ now.  Look, for example, at cp/optimize.c to see
> how inlining is done entirely on trees.  You could do a similar pass
> to add memory checking calls.
Ok, this is a starting point.
Note that this may be not so simple:
* I am not sure how to correctly handling SAVE_EXPR,

* a function has to be called for each argument pushed in the stack.  This
  cannot be done on trees, AFAIK.

Tristan.