[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:       "Smith, Kevin B" <kevin.b.smith () intel ! com>
Date:       2015-07-30 19:53:48
Message-ID: 4F440F6BE90FC64193D0A9A486C6274C9F7D1EDF () FMSMSX103 ! amr ! corp ! intel ! com
[Download RAW message or body]

[Attachment #2 (text/plain)]


From: cfe-dev-bounces@cs.uiuc.edu [mailto:cfe-dev-bounces@cs.uiuc.edu] On Behalf Of \
                Sean Silva
Sent: Thursday, July 30, 2015 12:02 PM
To: Eric Christopher
Cc: Vedant Kumar; Clang
Subject: Re: [cfe-dev] [PROPOSAL] Reintroduce guards for Intel intrinsic headers



On Thu, Jul 30, 2015 at 11:33 AM, Eric Christopher \
<echristo@gmail.com<mailto:echristo@gmail.com>> wrote:

On Thu, Jul 30, 2015 at 11:27 AM Vedant Kumar <vsk@apple.com<mailto:vsk@apple.com>> \
wrote:
> On Jul 30, 2015, at 10:33 AM, Eric Christopher \
> <echristo@gmail.com<mailto:echristo@gmail.com>> wrote: 
> > I don't see any downsides to reintroducing these guards.
> 
> Then you weren't really paying attention to the point of removing them :)
> 
> The idea is so that the headers can be used, with appropriate target attributes, \
> for any code.

Right, I thought about this but wasn't sure if there were benefits to having symbols \
available for an unsupported target.

I.e, is there some reason a project might want to include the header for SSE4 \
intrinsics if it can't use any of those symbols?

I put a code snippet for something to do in the commit, but the general idea is that \
you can compile a function for a specific target with subtarget features and use the \
target attribute to add subtarget features and you'll want to be able to use the \
intrinsics at the same time. It won't work if you block them at the preprocessor \
level.


Sorry if this is a stupid question, but would it make sense to gate this behind a \
flag? Breaking user code is bad, bad news. This target attribute stuff is pretty \
niche, so it would make sense to have it be opt-in.

Or is this how GCC/ICC have always done it? I would expect user code to not be \
breaking if that were the case though.

KBS> ICC considers all intrinsics to be available in any environment, regardless of \
the compiler switches.  So, you can be generating code assuming you are targeting a \
plain old Pentium Processor and use AVX512 intriniscs (for example).  We specifically \
choose this model, and consider that if such an intrinsic is used, it implies that \
the user has done the necessary checks to ensure that the processor they are running \
on, supports the intrinsics in use in whatever context that happens to be.  And we \
can propogate that "cpu assertion" around a bit in the control-flow-graph. We felt \
this model was necessary to allow code to be developed which did the following:

if (some condition that is only set for a certain processor) {
   // Use processor specific intrinsics to support optimized code for some algorithm \
based on the dynamic check above. }

My understanding is that neither gcc nor clang/LLVM really support this type of \
usage.  Because in order to use say an AVX intrinsic, the whole module that the \
intrinsic is used in needs to be compiled with the compiler switch targeting AVX, \
potentially allowing AVX instructions outside the "safe" area.  Or for some \
intrinsics (if you get around of ifdef guards), you simply will lower them to a set \
of instructions that implements a similar operation, but without using the wider \
vector the user really intended.

Kevin B. Smith

-- Sean Silva



I'm just not 100% convinced that removing the header guards was necessary (which, I \
admit, could just be due to a lack of understanding on my part).

Did the above help?

-eric

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


[Attachment #3 (text/html)]

<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.hoenzb
	{mso-style-name:hoenzb;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Arial","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
 <p class="MsoNormal"><b><span \
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span \
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> \
cfe-dev-bounces@cs.uiuc.edu [mailto:cfe-dev-bounces@cs.uiuc.edu] <b>On Behalf Of \
</b>Sean Silva<br> <b>Sent:</b> Thursday, July 30, 2015 12:02 PM<br>
<b>To:</b> Eric Christopher<br>
<b>Cc:</b> Vedant Kumar; Clang<br>
<b>Subject:</b> Re: [cfe-dev] [PROPOSAL] Reintroduce guards for Intel intrinsic \
headers<o:p></o:p></span></p> <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal">On Thu, Jul 30, 2015 at 11:33 AM, Eric Christopher &lt;<a \
href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>&gt; \
wrote:<o:p></o:p></p> <div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Jul 30, 2015 at 11:27 AM Vedant Kumar &lt;<a \
href="mailto:vsk@apple.com" target="_blank">vsk@apple.com</a>&gt; \
wrote:<o:p></o:p></p> </div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in \
6.0pt;margin-left:4.8pt;margin-right:0in"> <p class="MsoNormal" \
style="margin-bottom:12.0pt">&gt; On Jul 30, 2015, at 10:33 AM, Eric Christopher \
&lt;<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>&gt; \
wrote:<br> &gt;<br>
&gt;&gt; I don't see any downsides to reintroducing these guards.<br>
&gt;<br>
&gt; Then you weren't really paying attention to the point of removing them :)<br>
&gt;<br>
&gt; The idea is so that the headers can be used, with appropriate target attributes, \
for any code.<br> <br>
Right, I thought about this but wasn't sure if there were benefits to having symbols \
available for an unsupported target.<br> <br>
I.e, is there some reason a project might want to include the header for SSE4 \
intrinsics if it can't use any of those symbols?<o:p></o:p></p> </blockquote>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">I put a code snippet for something to do in the commit, but the \
general idea is that you can compile a function for a specific target with subtarget \
features and use the target attribute to add subtarget features and you'll want to be \
able  to use the intrinsics at the same time. It won't work if you block them at the \
preprocessor level.<o:p></o:p></p> </div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
Sorry if this is a stupid question, but would it make sense to gate this behind a \
flag? Breaking user code is bad, bad news. This target attribute stuff is pretty \
niche, so it would make sense to have it be opt-in.<o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">Or is this how GCC/ICC have always done it? I would expect user \
code to not be breaking if that were the case though.<o:p></o:p></p> <p \
class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
 <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D">KBS&gt; \
ICC considers all intrinsics to be available in any environment, regardless of the \
compiler switches.&nbsp; So, you can be generating code assuming you are targeting  a \
plain old Pentium Processor and use AVX512 intriniscs (for example).&nbsp; We \
specifically choose this model, and consider that if such an intrinsic is used, it \
implies that the user has done the necessary checks to ensure that the processor they \
are running  on, supports the intrinsics in use in whatever context that happens to \
be.&nbsp; And we can propogate that "cpu assertion" around a bit in the \
control-flow-graph. We felt this model was necessary to allow code to be developed \
which did the following:<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
 <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D">if \
(some condition that is only set for a certain processor) {<o:p></o:p></span></p> <p \
class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;&nbsp; \
// Use processor specific intrinsics to support optimized code for some algorithm \
based on the dynamic check above.<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D">}<o:p></o:p></span></p>
 <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
 <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D">My \
understanding is that neither gcc nor clang/LLVM really support this type of \
usage.&nbsp; Because in order to use say an AVX intrinsic,<o:p></o:p></span></p> <p \
class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D">the \
whole module that the intrinsic is used in needs to be compiled with the compiler \
switch targeting AVX, potentially allowing AVX instructions outside the  "safe" \
area.&nbsp; Or for some intrinsics (if you get around of ifdef guards), you simply \
will lower them to a set of instructions that implements a similar operation, but \
without using the wider vector the user really intended.<o:p></o:p></span></p> <p \
class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
 <p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D">Kevin \
B. Smith<o:p></o:p></span></p> </div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">-- Sean Silva<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in \
6.0pt;margin-left:4.8pt;margin-right:0in"> <div>
<div>
<div>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in \
6.0pt;margin-left:4.8pt;margin-right:0in"> <p class="MsoNormal" \
style="margin-bottom:12.0pt"><br> I'm just not 100% convinced that removing the \
header guards was necessary (which, I admit, could just be due to a lack of \
understanding on my part).<o:p></o:p></p> </blockquote>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal">Did the above help?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">-eric&nbsp;<o:p></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" \
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><o:p></o:p></p> \
</blockquote> </div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</div>
</body>
</html>



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

--===============7871808759584897586==--

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

Configure | About | News | Add a list | Sponsored by KoreLogic