<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr"><div class="gmail_default" style>On Tue, Dec 18, 2012 at 2:07 PM, Michael Ilseman <span dir="ltr"><<a href="mailto:milseman@apple.com" target="_blank" class="cremed">milseman@apple.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Attached are patches for fast-math support for IntrinsicInst.</blockquote>
<div><br></div><div style>I have one specific concern:</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This includes bitcode changes to separate out IntrinsicInsts from CallInsts.<br>
</blockquote><div style><br></div><div style><snip></div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Previously, IntrinsicInsts were handled as CallInsts. However, intrinsics can now have fast-math flags, and thus merit a separate bitcode encoding. This change adds FUNC_CODE_INST_INTRINSIC for intrinsic calls, separates them out from general calls, and adds encoding and decoding of fast-math flags. Backwards compatibility is retained. Adds parsing fast-math flags for IntrinsicInsts, and more tests.<br>
</blockquote><div><br></div><div style>This seems like a terrible consequence of using flags instead of metadata. Why is this a good thing to do?</div><div style><br></div><div style>I think we either need to either not have fast math markers on intrinsics or provide metadata alternatives to the flags so we can use that pre-existing general mechanism for extending the set of information we have about a particular group of instructions.</div>
<div style><br></div><div style>Making calls to intrinsic functions less like any other call adds complexity to the entire IR just to support a few intrinsics and a few special-purpose optimizations.</div></div></div></div>
</div>