[llvm-commits] [llvm] r80428 - in /llvm/trunk: include/llvm/Target/TargetLowering.h lib/CodeGen/AsmPrinter/DwarfException.cpp lib/Target/PowerPC/PPCISelLowering.cpp lib/Target/PowerPC/PPCISelLowering.h lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h

[Bill Wendling]

On Aug 31, 2009, at 9:33 AM, Duncan Sands wrote:

> if the place that outputs the data already has enough info to get the
> format right, then doesn't that mean that the  
> getPreferredLSDADataFormat
> target hook is redundant?  It could presumably be implemented as a
> utility in DwarfException.cpp, and be driven by the same target info
> that is driving LSDA output.
[...]
> Sure, it should all be driven by a logical and orthogonal set of
> target information.  That's why I don't see the point of introducing
> a new target hook (getPreferredLSDADataFormat) which is not orthogonal
> at all, since it can apparently be calculated from existing target
> settings...
>
Sure. I suppose what I'm saying here is that I don't know the  
orthogonal set of conditions which need to be met to determine the  
data format at this point. I don't see anything in the LSDA output  
code which indicates that it's following orthogonal conditions. It's  
just outputting stuff.

>> It would probably be better to simply use the actual byte size of the
>> pointer. Though I'm not at all sure how that would work on machines  
>> with
>> ptrs > 8 bytes.
>
> I guess 16 bit machines are more likely :)  Anyway, the only real  
> point
> I want to make is that rather than having stuff like "if (4 bytes)  
> then
> x; else (y)" all over the place, it would be neater to have methods  
> that
> work without any assumptions on pointer sizes, even if no such  
> machines
> exist.
>
'Twould be a grand world if that were so.

-bw

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090831/ae2bb85f/attachment.html>