> I think you're semantically testing the wrong thing. > > It's not if unaligned accesses are supported, it's if they are > efficient enough or not. > > For example, sparc64 fully handles unaligned accesses but taking the > trap to fix it up is slow. So sparc64 "can" handle unaligned > accesses, but whether we want to set this symbol or not is another > matter. Yeah, good point. Should I rename it to HAVE_EFFICIENT_UNALIGNED_ACCESS or similar? Or have it defined as some sort of number so you can make actually make tradeoffs? Like Dave Woodhouse suggested at some point to have get_unaligned() take an argument that indicates the probability... johannes
Attachment:
signature.asc
Description: This is a digitally signed message part