[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: Sean Silva <chisophugis () gmail ! com>
Date: 2015-07-31 20:55:52
Message-ID: CAHnXoanvH5joYCG6b0o7tkSLTMxGs95mkeDppTwmde98L3_nSw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Jul 31, 2015 at 9:26 AM, Reid Kleckner <rnk@google.com> wrote:
> 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.
>
Did you see the thread "__attribute__((enable_if(...))) for de-macroifying
the builtin headers"? I think the macros can be disposed of using a
solution along those lines. There are some details to discuss, but the
fundamental approach I think can be made to work.
> 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)).
>
That would probably improve the state of things, but I still worry about
what the diagnostic quality would be.
-- Sean Silva
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul \
31, 2015 at 9:26 AM, Reid Kleckner <span dir="ltr"><<a \
href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote"><span>On Thu, Jul 30, 2015 at 2:53 PM, Robinson, Paul <span \
dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" \
target="_blank">Paul_Robinson@playstation.sony.com</a>></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:"Calibri","sans-serif";color:#1f497d">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.</span></p></div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div><div>Did you see the \
thread "__attribute__((enable_if(...))) for de-macroifying the builtin \
headers"? I think the macros can be disposed of using a solution along those \
lines. There are some details to discuss, but the fundamental approach I think can be \
made to work.</div><div><br></div><div><br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote"><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></blockquote><div><br></div><div>That \
would probably improve the state of things, but I still worry about what the \
diagnostic quality would be.</div><div><br></div><div>-- Sean Silva</div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" \
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br> \
<br></blockquote></div><br></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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic