From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22191 invoked by alias); 3 Mar 2003 15:43:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 22177 invoked from network); 3 Mar 2003 15:43:19 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by 172.16.49.205 with SMTP; 3 Mar 2003 15:43:19 -0000 Received: from nat-pool-rdu.redhat.com ([66.187.233.200] helo=lacrosse.corp.redhat.com) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18ps43-0000nY-00 for gcc@gcc.gnu.org; Mon, 03 Mar 2003 10:41:15 -0500 Received: from tornado.toronto.redhat.com (IDENT:dFb8uW+PWP0ohM9nolWd20V4tUpoYows@tornado.toronto.redhat.com [172.16.14.228]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h23FeEo29532 for ; Mon, 3 Mar 2003 10:40:14 -0500 Received: from tornado.toronto.redhat.com (localhost [127.0.0.1]) by tornado.toronto.redhat.com (8.12.5/8.12.5) with ESMTP id h23FeDSU030136 for ; Mon, 3 Mar 2003 10:40:14 -0500 Received: (from dnovillo@localhost) by tornado.toronto.redhat.com (8.12.5/8.12.5/Submit) id h23FeDPF030134; Mon, 3 Mar 2003 10:40:13 -0500 X-Authentication-Warning: tornado.toronto.redhat.com: dnovillo set sender to dnovillo@redhat.com using -f Subject: [tree-ssa] coding style for structure fields From: Diego Novillo To: "gcc@gcc.gnu.org" Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 03 Mar 2003 16:33:00 -0000 Message-Id: <1046706013.29022.11.camel@tornado> Mime-Version: 1.0 X-SW-Source: 2003-03/txt/msg00095.txt.bz2 For statement and variable annotations, we have a set of inline functions that given a tree, they set or get the corresponding field in the tree annotation. I think I'm getting sick of this. I see two problems: 1. The interface to these inline functions is convenient, but it may cause unnecessary calls to the functions that retrieve the tree annotation. It is not uncommon for a function to retrieve several different annotations for the same statement. At the very least, I would like to change the interface so that instead of a 'tree', we provide an annotation directly. 2. I've always disliked get/set accessors. I don't mind get accessors, but when I'm modifying a field, I'd like to see an assignment. The alternative is to wrap these accessors in lvalue-macros like the TREE_* macros. I don't think I like that too much either. I realize that these stylistic issues are highly subjective, but I'd like to get an idea of what other folks think. Should we move inline with the rest of GCC and use lvalue-macros? Should we maintain the current get/set inline macros? For #1, I will probably change the interface soon because it's more of a performance issue. Diego.