From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-412326-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 74498 invoked by alias); 2 Nov 2015 09:55:30 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 74483 invoked by uid 89); 2 Nov 2015 09:55:30 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-yk0-f174.google.com
Received: from mail-yk0-f174.google.com (HELO mail-yk0-f174.google.com) (209.85.160.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 02 Nov 2015 09:55:29 +0000
Received: by ykba4 with SMTP id a4so134025422ykb.3        for <gcc-patches@gcc.gnu.org>; Mon, 02 Nov 2015 01:55:27 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.129.70.65 with SMTP id t62mr15619759ywa.240.1446458127056; Mon, 02 Nov 2015 01:55:27 -0800 (PST)
Received: by 10.37.117.136 with HTTP; Mon, 2 Nov 2015 01:55:26 -0800 (PST)
In-Reply-To: <20151030151938.GK37773@kam.mff.cuni.cz>
References: <20151014162944.GE16672@kam.mff.cuni.cz>	<1456448.Tt4DpGVrAE@polaris>	<20151021215701.GA14675@atrey.karlin.mff.cuni.cz>	<2210014.Qgk3pAbeYD@polaris>	<20151029033922.GA52478@kam.mff.cuni.cz>	<CAFiYyc2+HEuHcz8Mmp0PeoNvPiXVhv9-K2iRPMAG2Q7ZuFLzQg@mail.gmail.com>	<20151029150215.GA34652@kam.mff.cuni.cz>	<CAFiYyc1X4cDecZ0monVpxXSQ_ywu9anLRNBN9Ay4xx5_tLXtJw@mail.gmail.com>	<20151029155210.GQ5527@kam.mff.cuni.cz>	<CAFiYyc0WZ_Cxxxw4FvRZZVJDp_Epa1Lc8W6P+xJe6DBik4Z5Xw@mail.gmail.com>	<20151030151938.GK37773@kam.mff.cuni.cz>
Date: Mon, 02 Nov 2015 09:55:00 -0000
Message-ID: <CAFiYyc3VFgFt-s+rOCvMCs=8EdbBkKHC-RT+2m3x8WN1Aymorg@mail.gmail.com>
Subject: Re: Add VIEW_CONVERT_EXPR to operand_equal_p
From: Richard Biener <richard.guenther@gmail.com>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: Eric Botcazou <ebotcazou@adacore.com>, GCC Patches <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2015-11/txt/msg00042.txt.bz2

On Fri, Oct 30, 2015 at 4:19 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>
>> Yeah, I suppose we'd need to either build a new function type for each
>> variadic call
>> then or somehow represent 'fntype' differently (note that function
>> attributes also
>> need to be preserved).
>
> Why we can't keep fntype as it is, but simply add a new set of parameters to call stmt
> that lists their types?  We can then feed those types to expand_call (since we still go
> back to generic here I suppose we will just re-insert those VCEs in expand-cfg.c)

That would be quite expensive though ... (the extra list of parameters).

> Honza