On 5 sept. 2011, at 17:48, Duncan Sands wrote:> since the result of a multiply doesn't depend on the signedness, I find it > strange that your target differentiates between them. What I'm saying is > that if you have (say) two i32 numbers a and b and you do a signed multiply: > c = a *s b > and an unsigned multiply > d = a *u b > then c and d are the same number (exactly the same bits set).At least two architectures I know about have size-extending multiplication, for which your statement is not true: - Motorola MC68K has i16 x 16 -> i32 instructions in signed and unsigned forms - Itanium has signed and unsigned multiplications with i64 x i64 -> i64 where you can take the high or low part of the resulting i128. While xma.lu is a pseudo-op since it's the same as xma.lu, xma.hu and xma.h (unsigned and signed) are distinct. I'm pretty sure there are other similar architectures. Regards Christophe
Hi Christophe, On 05/09/11 18:35, Christophe de Dinechin wrote:> > On 5 sept. 2011, at 17:48, Duncan Sands wrote: > >> since the result of a multiply doesn't depend on the signedness, I find it >> strange that your target differentiates between them. What I'm saying is >> that if you have (say) two i32 numbers a and b and you do a signed multiply: >> c = a *s b >> and an unsigned multiply >> d = a *u b >> then c and d are the same number (exactly the same bits set). > > At least two architectures I know about have size-extending multiplication, for which your statement is not true:yup, and that's why LLVM codegen has the SMUL_LOHI/UMUL_LOHI etc nodes. However that's not relevant to ordinary multiplication (codegen MUL node) which is what I understand the question to be about. Ciao, Duncan.> > - Motorola MC68K has i16 x 16 -> i32 instructions in signed and unsigned forms > > - Itanium has signed and unsigned multiplications with i64 x i64 -> i64 where you can take the high or low part of the resulting i128. While xma.lu is a pseudo-op since it's the same as xma.lu, xma.hu and xma.h (unsigned and signed) are distinct. > > I'm pretty sure there are other similar architectures. > > > Regards > Christophe >
Charllls Alquarra
2012-Feb-05 21:45 UTC
[LLVMdev] Marking a function prototype as being "persistent"
on Jan 6, 2011 9:21 pm Christophe de Dinechin wrote:>On 7 janv. 2011, at 01:00, Duncan Sands wrote: >>That said, probably the reason you are getting improved optimization is due to >>running the "internalize" pass. If so be warned that it is not safe to run >>internalize unless all functions and their bodies are present in the module.>All functions and bodies are present, so that's not the issue. The issue is that >some inputs of LTO are destroyed as a side effect of running it.>>If you run internalize, optimize, and then later add a few more functions to the >>module all kinds of nasty subtle things can go wrong, not just those you saw >>with GlobalDCE.>Do you mean I should assume for example that the Functions I generated are also >irreversibly damaged? If so, what passes do I need to avoid if I want to >preserve the ability to do incremental recompilation?First of all, Sorry for waking up this zombie thread from jan 2011, but i'm investigating incremental compilation and i haven't found much else besides this. As a question to Christophe, but also to anyone that might help; are your functions being evicted from the final module after LTO *even* if the functions are created with External Linkage? notice the following points: 1) my understanding is that a function with external linkage should be always available. That is how libraries export their symbols after all. 2) my understanding also (and this is the crucial point) is that LTO as a optimization phase should be equally applicable to final executables or libraries. Libraries always should have their export/external symbols available even if they seem to not be called from inside the available code. (libraries would be very useless objects after all!). This does not (or *should not*) preclude LTO optimization of the library dependencies am i making sense here? thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120205/f46d1b42/attachment.html>