This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/9] ifcvt: Use enum instead of transform_name string.


On 8/6/19 2:42 PM, Richard Sandiford wrote:
> Robin Dapp <rdapp@linux.ibm.com> writes:
>> This patch introduces an enum for ifcvt's various noce transformations.
>> As the transformation might be queried by the backend, I find it nicer
>> to allow checking for a proper type instead of a string comparison.
> 
> TBH I think the names of internal ifcvt routines are too level to expose as
> an "official" part of the interface.  (OK, like you say, the information's
> already there and rogue backends could already check it if they wanted.)
> 
> If we were going to have an enum, I think it should be a higher-level
> description of what the converted code is going to do, rather than the
> name of the routine that's going to do it.
> 
> It sounded from the covering note that you might not need this
> any more though.
You're probably right on the naming.   I think the main question with
patch #1 and #2 is whether or not targets would likely use that information.

My sense is that arm & aarch64 want to be doing if-conversion very
aggressively and likely wouldn't care about them.  On x86 if-conversion
costing seems more complex -- in fact, I don't think we really have a
clear picture of what the costing factors really are for x86.  It sounds
like at least for the issues Robin is addressing that s390 won't care.

So my inclination would be to defer #1 and #2 until a particular target
indicates that it needs this information.  If that happens, we dust off
patches #1 and #2.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]