Hi,
As I learned from experience, gcc always assume independence between memory
references in the following program:
typedef struct {
int m1;
int m2;
} S1;
void foo(S1 *p1, S1 *p2) {
... = p1->m1;
... = p2->m2;
}
...even if -fno-strict-aliasing (an option disabling ansi-aliasin
On 20 June 2007 11:36, Bokhanko, Andrey S wrote:
> Hi,
>
> As I learned from experience, gcc always assume independence between memory
> references in the following program:
>
> typedef struct {
> int m1;
> int m2;
> } S1;
>
> void foo(S1 *p1, S1 *p2) {
> ... = p1->m1;
> ... =
"Bokhanko, Andrey S" <[EMAIL PROTECTED]> writes:
> Hi,
>
> As I learned from experience, gcc always assume independence between
> memory references in the following program:
>
> typedef struct {
> int m1;
> int m2;
> } S1;
>
> void foo(S1 *p1, S1 *p2) {
> ... = p1->m1;
> ... = p2->
On 6/20/07 6:35 AM, Bokhanko, Andrey S wrote:
> As I learned from experience, gcc always assume independence between memory
> references in the following program:
>
> typedef struct {
> int m1;
> int m2;
> } S1;
>
> void foo(S1 *p1, S1 *p2) {
> ... = p1->m1;
> ... = p2->m2;
> }
Exctracted from
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt:
date compile execute
070608 106.29 628.74
070615 117.43 629.73
070620 105.95 616.99
So these tests show a ~10% increase of the compilation time
from 070612 to 070618. I have forgotten to mention tha
Diego Novillo wrote:
> No, it doesn't. Both p1->m1 and p2->m2 will use the same memory tag
in
> GIMPLE and the same alias set during RTL. Notice how a store between
> the two loads affects the second load:
>
> # VUSE
> x_2 = p1_1(D)->m1;
>
> # SMT.4_8 = VDEF
> p1_1(D)->m1 = 32;
>
>
Actually, I'm interested in how to force conservative analysis *without*
source code modifications (only with compiler's options).
Yours,
Andrey
Hi,
On Tue, 19 Jun 2007, Kenneth Zadeck wrote:
> The reason that there is no reg_dead not in the last use (insn 45)
> before the sib_call (insn 46) is that there is no def for r0 in the
> sibcall (insn 46) and r0 is live at the end of the block.
>
> This of course changes the question to not wh
(cross-posting because discussion may be interesting to others)
The following is a patch that re-structures
tree_ssa_useless_type_conversion_1 (without changing its semantics) to
make it easier to read and fix towards not requiring the
types_compatible_p langhook. Several places that have prob
On 6/20/07, Dominique Dhumieres <[EMAIL PROTECTED]> wrote:
Exctracted from
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt:
date compile execute
070608 106.29 628.74
070615 117.43 629.73
070620 105.95 616.99
So these tests show a ~10% increase of the compilation
Roman Zippel wrote:
> Hi,
>
> On Tue, 19 Jun 2007, Kenneth Zadeck wrote:
>
>
>
> Another question I have is about DF_REF_MAY_CLOBBER, any function call
> would also clobber the return value and I see defs generated for calls,
> but they are only marked with DF_REF_MAY_CLOBBER and thus the use c
Hi,
On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
> For certain regs, the subroutine may or may not modify the value. The
> better information alluded to is information that one might get by doing
> interprocedural analysis. Without such information you have to assume
> that the value may or may n
> Maybe you can identify the single most increase for ppc?
The ranking is:
compile
06/15 06/08%
channel 4.289 2.519 70
induct 36.87823.671 56
protein 20.09713.162 53
nf 5.412 3.629 49
fa
On 6/20/07 7:52 AM, Bokhanko, Andrey S wrote:
> typedef struct {
> int s1_m1;
> int s1_m2;
> } S1;
>
> void foo(S1 *p1, S1 *p2) {
> p2->s1_m1 = p1->s1_m2 * 11;
> /* If ansi-aliasing happens, this MUL shold be removed. */
> p2->s1_m1 = p1->s1_m2 * 11;
>
> return;
> }
>
>
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
>
>
>> For certain regs, the subroutine may or may not modify the value. The
>> better information alluded to is information that one might get by doing
>> interprocedural analysis. Without such information you have to as
On 6/20/07, Ben Elliston <[EMAIL PROTECTED]> wrote:
To now answer my own question (for the benefit of others): the CC1_SPEC
string can include the sequence %
This is not a good way, the best way is to create a dumby -moption in
the target.opt file so you get the documentation with --help.
-- Pi
On 6/20/07, Dominique Dhumieres <[EMAIL PROTECTED]> wrote:
> Maybe you can identify the single most increase for ppc?
The ranking is:
compile
06/15 06/08%
channel 4.289 2.519 70
induct 36.87823.671 56
protein 20.09713.162
> Structural analysis let's you prove that stores to fields m1 and m2
may
> never overlap. They're always at different offsets, even if p1 and p2
> point to the same area.
Yes, but one can write something like this:
p2 = (S1 *)&p1->s1_m2;
Of course, this is a blatant violation of ANSI C standa
On 6/20/07 9:09 AM, Bokhanko, Andrey S wrote:
> Yes, but one can write something like this:
>
> p2 = (S1 *)&p1->s1_m2;
>
> Of course, this is a blatant violation of ANSI C standard, etc. Still, a
> perfectly acceptable C code.
No, it isn't. GCC only tries to DTRT on standard compliant code.
>
On Wed, Jun 20, 2007 at 09:26:39AM -0400, Diego Novillo wrote:
> Having said that, maybe we could consider having CSE not doing this with
> -fno-strict-aliasing, but I'm not sure if it's a good idea. What do
> others think?
I haven't seen a useful reason in this thread why you would want to do
so
Hi,
On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
> > I don't understand, wouldn't the consertive approach be that the value
> > simply doesn't survive?
> >
> No, the conservative is that we do not know anything. it could be
> destroyed and it could not be destroyed.
What is the value of this? I
Hi,
On Wed, 20 Jun 2007, Richard Guenther wrote:
> /* If the outer type is (void *), then the conversion is not
> necessary.
> ??? This makes tree_ssa_useless_type_conversion_1 not
> transitive. */
Not this line itself makes it not transitive, but the fact that
Diego Novillo <[EMAIL PROTECTED]> writes:
> On 6/20/07 9:09 AM, Bokhanko, Andrey S wrote:
>
> > Yes, but one can write something like this:
> >
> > p2 = (S1 *)&p1->s1_m2;
> >
> > Of course, this is a blatant violation of ANSI C standard, etc. Still, a
> > perfectly acceptable C code.
>
> No, i
On Wed, 20 Jun 2007, Michael Matz wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Richard Guenther wrote:
>
> > /* If the outer type is (void *), then the conversion is not
> > necessary.
> > ??? This makes tree_ssa_useless_type_conversion_1 not
> > transitive. */
>
> N
On 6/20/07, Michael Matz <[EMAIL PROTECTED]> wrote:
Hi,
On Wed, 20 Jun 2007, Richard Guenther wrote:
> /* If the outer type is (void *), then the conversion is not
> necessary.
> ??? This makes tree_ssa_useless_type_conversion_1 not
> transitive. */
Not this
Hi,
On Wed, 20 Jun 2007, Andrew Pinski wrote:
> On 6/20/07, Michael Matz <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On Wed, 20 Jun 2007, Richard Guenther wrote:
> >
> > > /* If the outer type is (void *), then the conversion is not
> > > necessary.
> > > ??? This makes tr
On Wed, 20 Jun 2007, Daniel Jacobowitz wrote:
> On Wed, Jun 20, 2007 at 09:26:39AM -0400, Diego Novillo wrote:
> > Having said that, maybe we could consider having CSE not doing this with
> > -fno-strict-aliasing, but I'm not sure if it's a good idea. What do
> > others think?
>
> I haven't seen
Hi Richard,
what about moving all the type-system related functions to a new file,
eg: tree-ssa-type.c? I think that makes the intent even clearer.
--
Giovanni Bajo
On Wed, 20 Jun 2007, Giovanni Bajo wrote:
> Hi Richard,
>
> what about moving all the type-system related functions to a new file, eg:
> tree-ssa-type.c? I think that makes the intent even clearer.
While this is surely a good idea I'd like to do this separately to not
make diffs unnecessarily la
On 20 June 2007 15:25, Andrew Pinski wrote:
> On 6/20/07, Michael Matz <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> On Wed, 20 Jun 2007, Richard Guenther wrote:
>>
>>> /* If the outer type is (void *), then the conversion is not
>>> necessary. ??? This makes tree_ssa_useless_ty
> /* Return true if the conversion from INNER_TYPE to OUTER_TYPE is a
> !useless type conversion, otherwise return false.
> !This function implicitly defines the middle-end type system. The
> !following invariants shall be fulfilled:
> !
> ! 1) tree_ssa_useless_type_conversion_1
Hi,
On Wed, 20 Jun 2007, Eric Botcazou wrote:
> > ! 2) tree_ssa_useless_type_conversion_1 is not communtative.
> > ! From a < b does not follow a > b.
> > !
> > ! 3) Conversions are useless only if with the resulting type
> > ! can be used in a subset of the operations the original
On Jun 20, 2007, at 4:57 AM, Bokhanko, Andrey S wrote:
Actually, I'm interested in how to force conservative analysis
*without*
source code modifications (only with compiler's options).
While we'd recommend using a language called C, you might be able to
use -O0 or older compilers (3.3 and
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
>
>
>>> I don't understand, wouldn't the consertive approach be that the value
>>> simply doesn't survive?
>>>
>>>
>> No, the conservative is that we do not know anything. it could be
>> destroyed and it could not
On Tue, Jun 19, 2007 at 08:47:36PM -0700, Mark Mitchell wrote:
> I think we want to avoid making the same mistake we did last time:
> mixing these changes up with LTO. They will help LTO (by reducing
> memory use), but they're logically independent. So, if we're not
> comfortable putting the chan
michael.a wrote:
>
>
> So, I really appreciate all of your patience in helping to get me through
> the build process. I guess I'll post something about how the hacking
> effort / reprogramming expiriments work out. In the meantime I hope this
> discussion (and the relevance of a proper extensi
Hi,
On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
> If we add the dead note there we are asserting that the value is
> modified by the caller. however it might not be and someone could write
> a piece of asm right after the call to use that reg if the person knew
> that the reg was not modified by t
having the dead note there is asserting to the register allocator that
they are free to use that reg after the calll in any way that it wants
and there is a (small) possibility that is wrong.
IMO there is nothing wrong with this.
I agree with Roman. You can always put your call into an asm
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
>
>
>> If we add the dead note there we are asserting that the value is
>> modified by the caller. however it might not be and someone could write
>> a piece of asm right after the call to use that reg if the person knew
>>
Paolo Bonzini wrote:
>
>>> having the dead note there is asserting to the register allocator that
>>> they are free to use that reg after the calll in any way that it wants
>>> and there is a (small) possibility that is wrong.
>>
>> IMO there is nothing wrong with this.
>
> I agree with Roman. You
This is one of the places where i slavishly copied what flow did. if
you want to change this, go test it on at least 7 platforms and fix all
of the problems that it causes.
I see. Can one of you recap how it relates to the m68k problem, though? :-)
Paolo
Michael Meissner wrote:
> I think a gradual approach is the right way. I think this can be done in the
> stage 2 time frame, but it could be pushed to gcc 4.4 (but we will have the
> same problem as we have now). The way I see it, the steps would be:
>
> 1) Add the basic infrastructure, iterato
On Jun 19, 2007, at 7:49 AM, Richard Earnshaw wrote:
On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
I suspect that the realview compiler accepts
this as an oversight or a bug, not as an intentional feature.
Let's ask.
Richard E., is the fact that RealView 3.0SP1 accepts:
class _
Kenneth Zadeck wrote:
Paolo Bonzini wrote:
having the dead note there is asserting to the register allocator that
they are free to use that reg after the calll in any way that it wants
and there is a (small) possibility that is wrong.
IMO there is nothing wrong with this.
I agree with Roman.
Bernd Schmidt wrote:
> Kenneth Zadeck wrote:
>> Paolo Bonzini wrote:
> having the dead note there is asserting to the register allocator
> that
> they are free to use that reg after the calll in any way that it
> wants
> and there is a (small) possibility that is wrong.
IMO
So, I think I am still not convinced which way we want to access the RHS
of a GS_ASSIGN.
Since GS_ASSIGN can have various types of RHS, we originally had:
gs_assign_unary_rhs (gs)<- Access the only operand on RHS
gs_assign_binary_rhs1 (gs) <- Access the 1st RHS operand
gs_assign_bin
Chris Lattner wrote:
> This description also makes sense, but is different than what was
> described before. To me, this description/implementation is extremely
> problematic, because the extension cannot be described without
> describing the implementation (specifically presence of vtables etc),
On Wed, 2007-06-20 at 14:19 -0400, Diego Novillo wrote:
>
> gs_assign_unary_rhs (gs) <- Access the only operand on RHS
> gs_assign_binary_rhs1 (gs)<- Access the 1st RHS operand
> gs_assign_binary_rhs2 (gs)<- Access the 2nd RHS operand
>
> And the corresponding _set functions.
>
> I
Hi,
On Wed, 20 Jun 2007, Paolo Bonzini wrote:
> > This is one of the places where i slavishly copied what flow did. if
> > you want to change this, go test it on at least 7 platforms and fix all
> > of the problems that it causes.
>
> I see. Can one of you recap how it relates to the m68k probl
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Paolo Bonzini wrote:
>
>
>>> This is one of the places where i slavishly copied what flow did. if
>>> you want to change this, go test it on at least 7 platforms and fix all
>>> of the problems that it causes.
>>>
>> I see. Can one of yo
On Wed, Jun 20, 2007 at 10:47:00AM -0700, Mark Mitchell wrote:
> Michael Meissner wrote:
>
> > I think a gradual approach is the right way. I think this can be done in
> > the
> > stage 2 time frame, but it could be pushed to gcc 4.4 (but we will have the
> > same problem as we have now). The w
Snapshot gcc-4.2-20070620 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070620/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hello,
> So, I think I am still not convinced which way we want to access the RHS
> of a GS_ASSIGN.
>
> Since GS_ASSIGN can have various types of RHS, we originally had:
>
> gs_assign_unary_rhs (gs) <- Access the only operand on RHS
> gs_assign_binary_rhs1 (gs)<- Access the 1st RHS oper
On Jun 19, 2007, at 10:50 PM, Pompapathi V Gadad wrote:
Hello,
Current function declaration of __bswapdi2 in libgcc2.h is:
DItype __bswapdi2 (DItype u)
Since this declaration does not check if DItype is supported, it is
bound for compilation failure for targets that do not support
DItype.
On 6/20/07 7:13 PM, Zdenek Dvorak wrote:
> I may be missing something, but surely having the accessors uniform
> would be better? So that I can write things like
>
> /* Process all operands. */
> for (i = 0; i < n_operands (gs); i++)
> process (gs_assign_rhs (gs, i));
Yeah, we already have t
michael.a wrote:
>
> I should probably just find that Debian patch and install into the system
> directories, but I still don't understand if there are any factors outside
> of gcc necessary for a successful build (could glibc be related to the
> crt.o files -- and are the crt.o files tied to t
This patch
http://gcc.gnu.org/ml/java-patches/2007-q2/msg00322.html
breaks libjava build:
/net/gnu-13/export/gnu/src/gcc/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:700:
error: prototype for 'gnu::classpath::jdwp::util::MethodResult*
gnu::classpath::jdwp::VMVirtualMachine::executeMetho
On Wed, Jun 20, 2007 at 07:31:44PM -0700, michael.a wrote:
> michael.a wrote:
> > I should probably just find that Debian patch and install into the system
> > directories, but I still don't understand if there are any factors outside
> > of gcc necessary for a successful build (could glibc be rela
H. J. Lu wrote:
This patch
http://gcc.gnu.org/ml/java-patches/2007-q2/msg00322.html
breaks libjava build:
/net/gnu-13/export/gnu/src/gcc/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:700:
error: prototype for 'gnu::classpath::jdwp::util::MethodResult*
gnu::classpath::jdwp::VMVirtualMac
Hello Eric,
The target I am working on is 16-bit target and cannot support 64-bit
data types (DI mode).
How about conditionally declare the function?
#if LONG_LONG_TYPE_SIZE > 32
extern DItype __bswapdi2 (DItype);
#endif
Thanks,
Pompa
Eric Christopher wrote:
On Jun 19, 2007, at 10:50 PM, Po
Cat-4 wrote:
>
> $ ls -lad gcc*
> 4 drwxr-xr-x 3 root root 4096 2007-06-21 12:35 gcc-4.1-4.1.1ds2
> 6956 -rw--- 1 root root 7109677 2006-12-11 06:02
> gcc-4.1_4.1.1ds2-21.diff.gz
> 4 -rw--- 1 root root 2407 2006-12-11 06:02
> gcc-4.1_4.1.1ds2-21.dsc
> 36156 -rw---
michael.a wrote:
>
> I guess in the meantime I'll go ahead and install it and see if I can use
> it or not.
>
Success!
Will likely be a good while before I can report whether simply knocking out
the errors cause any run-time issues.
In the meantime, if anyone can clue me in on squaring mul
David Daney wrote:
Keith, did you forget to update VMVirtualMachine.h?
Update, no. Commit, yes. Foo.
It would appear so.
If you are in a hurry and have the requisite tools installed, configure
with --java-maintainer-mode to regenerate the file yourself.
I've committed the regenerated fil
63 matches
Mail list logo
