On 21 September 2010 19:19, Bob Wilson <bob.wilson at apple.com> wrote:> There's no reason to have clang builtins for operations that can be represented directly. It just bloats the compiler. Please don't do that.Ok, so why are some in there already? There is a validation pass (in a pretty generic place, not ARM related: VMCore/AutoUpgrade.cpp) that filters them out as plain instructions. Shouldn't them get removed as well? -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
On Sep 21, 2010, at 11:59 AM, Renato Golin wrote:> On 21 September 2010 19:19, Bob Wilson <bob.wilson at apple.com> wrote: >> There's no reason to have clang builtins for operations that can be represented directly. It just bloats the compiler. Please don't do that. > > Ok, so why are some in there already? There is a validation pass (in a > pretty generic place, not ARM related: VMCore/AutoUpgrade.cpp) that > filters them out as plain instructions. Shouldn't them get removed as > well?That code is to support reading old bitcode files containing intrinsics that no longer exist or that have different arguments/usage than in previous versions of llvm. It's not a validation pass, and it's not relevant to any new IR. It's only for backward compatibility.
On 21 September 2010 20:02, Bob Wilson <bob.wilson at apple.com> wrote:> That code is to support reading old bitcode files containing intrinsics that no longer exist or that have different arguments/usage than in previous versions of llvm. It's not a validation pass, and it's not relevant to any new IR. It's only for backward compatibility.Oh, I see. So we should also change ARMInstrNEON.td that still have the intrinsic names on the definitions (ie. is still possible to generate those intrinsics at all?). -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm