Tim, Sorry, I'm not sure I understand your point here. See my comments below, and I'm still trying to understand your point.
Thanks, -Jiangning 2013/11/22 Tim Northover <[email protected]> > > As I mentioned previously in this email thread, the scenario for this > case > > is different from table lookup. We do have instruction directly map to > this > > intrinsic directly. The operand conversion between 64-bit and 128-bit > should > > be able to be solved by EXTRACT_SUBREG and SUBREG_TO_REG, > > It certainly *can* be, and my complaint isn't about that. I love > EXTRACT and friends since they're often free! This sounds good, and we are suggesting using EXTRACT_SUBREG and friends, so we are on the same page, right? > My complaint is that > we're effectively introducing an unnecessary set of intrinsics I don't understand about this. Can you explicitly point out what intrinsics names are really unnecessary? > (OK, so > they have the same base name as ones that are more useful[*], but > they're still extra backend burden) Do you mean using EXTRACT_SUBREG and friends is a backend burden? > for something that's representable > at the IR level. > > Cheers. > > Tim. > > [*] Though, now that I think of it, even those ought to be expressible > as IR. Something for the future, I suppose. > -- Thanks, -Jiangning
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
