'Re: [cfe-dev] [PROPOSAL] Reintroduce guards for Intel intrinsic headers'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] [PROPOSAL] Reintroduce guards for Intel intrinsic headers
From:       Reid Kleckner <rnk () google ! com>
Date:       2015-07-31 16:26:10
Message-ID: CACs=tyKFTJxDdZZPnDr9nGYuG0-tm2gDRV6BJXu8MECGPauOnA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

On Thu, Jul 30, 2015 at 2:53 PM, Robinson, Paul <
Paul_Robinson@playstation.sony.com> wrote:

> The problem that we reported in PR24125 is fundamentally that for
> intrinsics implemented as macros (rather than inline functions) the symptom
> for "you didn't set the right target" is a backend crash. For those
> intrinsics there's no function to attach the attribute to.  I was thinking
> about re-introducing the #ifdefs for those cases, so we'd be going back to
> the "undefined identifier" diagnostic from the frontend.  But I'd be
> happier with some other solution that worked more smoothly for macros.
>

The macro intrinsics are pretty gnarly. I'd love it if we could come up
with a principled solution to the general problem of always_inline
functions that need to propagate constant parameters into their bodies.

Barring a solution to the general problem, we could at least address
PR24125 by having all the macros call an artificial empty inline function
with __attribute__((target)).

[Attachment #5 (text/html)]

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 30, 2015 \
at 2:53 PM, Robinson, Paul <span dir="ltr">&lt;<a \
href="mailto:Paul_Robinson@playstation.sony.com" \
target="_blank">Paul_Robinson@playstation.sony.com</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">

<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">The \
problem that we reported in PR24125 is fundamentally that for intrinsics implemented \
as macros (rather than inline functions) the symptom for &quot;you didn&#39;t  set \
the right target&quot; is a backend crash. For those intrinsics there&#39;s no \
function to attach the attribute to.   I was thinking about re-introducing the \
#ifdefs for those cases, so we&#39;d be going back to the &quot;undefined \
identifier&quot; diagnostic from the frontend.    But I&#39;d be happier with some \
other solution that worked more smoothly for \
macros.</span></p></div></div></blockquote><div><br></div><div>The macro intrinsics \
are pretty gnarly. I&#39;d love it if we could come up with a principled solution to \
the general problem of always_inline functions that need to propagate constant \
parameters into their bodies.</div><div><br></div><div>Barring a solution to the \
general problem, we could at least address PR24125 by having all the macros call an \
artificial empty inline function with \
__attribute__((target)).</div></div></div></div>

_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

[prev in list] [next in list] [prev in thread] [next in thread] 