From: Eric Christopher [mailto:echristo@gmail.com] Sent: Thursday, July 30, 2015 12:56 PM To: Smith, Kevin B; Sean Silva Cc: Vedant Kumar; Clang Subject: Re: [cfe-dev] [PROPOSAL] Reintroduce guards for Intel intrinsic headers 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. We (recently) and gcc (in 4.4?) moved away from this and more to a method that you've got. We both do it on a function by function basis rather than in code blocks. -eric KBS> I noticed the changes that you had made to the header files Eric. I like the change ☺ and added flexibility it allows for the user. 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 http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev