From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6818 invoked by alias); 22 Jun 2004 19:50:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 6808 invoked from network); 22 Jun 2004 19:50:53 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org with SMTP; 22 Jun 2004 19:50:53 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA09590; Tue, 22 Jun 04 15:52:25 EDT Date: Tue, 22 Jun 2004 20:54:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10406221952.AA09590@vlsi1.ultra.nyu.edu> To: rth@redhat.com Subject: Re: Patch to allow Ada to work with tree-ssa Cc: gcc-patches@gcc.gnu.org X-SW-Source: 2004-06/txt/msg01788.txt.bz2 If we're going to change anything here, I'd prefer that the gimplifier handle NULL as an empty statement. Then we don't have to allocate anything or merge anything. Interesting idea. Probably worth it, though. I should have been more clear. Fortran has plans to use this field for stride different than size. OK, but array_ref_element_size looks at that field only if it's set. Before gimplification, it's not and it returns the actual element size. Are Fortran's plans consistent with that? Not really. There are only two things that highest_pow2_factor is going to see given gimple input: a constant or variable times constant. Which means that you can just as well use the TYPE_ALIGN when given a non-constant. Using TYPE_ALIGN doesn't work because you don't know whether all the fields in the path are aligned that way. They might be "bit fields" that are misaligned. Before highest_pow2_factor and the MEM_ALIGN addition, we used to get this wrong a lot. Now we are very precise. Also, the whole point of what I did is that highest_pow2_factor *will* see the multiply! get_inner_reference will call array_ref_element_size which will generate the multiplication (in the variable case). > Right. It doesn't seem worth the trouble here. Meaning the comment is incorrect. I'll go back and look at the code, but I think I just copied the comment, and didn't add it ... > Because get_inner_reference doesn't support IMAGPART_EXPR and > REALPART_EXPR. It seemed cleaner to break up the two cases since they > are handled differently. I disagree. It's just another accessor. Feed the whole lot to expand_expr and you'll get the right answer anyway. Sure, but by that argument we can allow > in GIMPLE! My point is that REALPART_EXPR and IMAGPART_EXPR have inputs and outputs that are both scalars, so it would seem more in keeping with the GIMPLE strategy to not mix them with other operations. So you've got a reference a.b.c.d.e in which, say, b is volatile? So why are you removing the c.d.e bits of the componentry, so that you access more of b than the user intended? Good point. I'll have to investigate that again. If my memory is correct, this was motivated by a C or C++ testcase, not Ada. > I'll have to investigate that: I never heard of list_p. Yes you have. It's the list argument to append_to_statemnt_list. Meaning taking a "tree *" in which to put statements is a better option than returning a statement list. Oh! If you'd said stmt_p, I would have known what you meant. Yes, I think you're right: I'll change that. No, you don't abort, gimplify_expr aborts. Just don't provide the post queue. OK.