search for: hfa

Hi Tim > I'm not sure I follow this point. Is preserving the source language a bad > thing for some reason I'm missing? Certainly, if it affects optimisation it > would be. Let's consider one example: union { float foo[4]; int bar[3]; }; This is definitely not a HFA. However, such a union can be represented via several different things in LLVM IR: [4 x float], [4 x i32], [32 x i8] (all involving bitcasts to access one of the fields of a union). And here we have a problem: 4 x float can be thought as HFA at IR level, however it's certainly not since the HFA...

...ake writing an ABI-compliant front-end as easy as possible. After that it should aim to have a sane ABI for hand-written LLVM code, and finally it should try to follow the ABI itself where possible (the last two are possibly interchangeable, but the first is primary). The current situation with HFAs is that, without changes to make the backend aware of the concept, the front-end needs to know the entire sequence of previous arguments and how LLVM lowers them to work out how to pass an HFA correctly. The goal I'd like to see reached is that a front-end should be able to map one of it...

...ew (for both our uses). It's also information that's readily available when InputArg/OutputArgs are being constructed. In your case: CCIf<"SourceTy->isPointerTy()", CCAssignToReg<[P1, P2]>>; I've got a patch which implements it for ARM and X86 (though not HFAs using the features yet, I'm still musing on the best interface to present there -- "HFA* byval" for target simplicity or "HFA" for user simplicity), I'll see if I can clean it up for other targets and send it for comparison. The main issue with my approach is that s...

...er arguments. When deciding whether to pass an argument as a homogeneous aggregate, one of the criteria is that the entire aggregate has to fit into the remaining unused argument registers, right? I tend to think that if every front-end has to implement the entire VFP PCS to decide how to pass an HFA, something has gone wrong. So I've come to the conclusion that the real flaw is LLVM not exposing enough information to the target-dependent backend code for it to do the right thing. By the time the target is involved, all that remains of any composite type is: * The fields completely separa...

...9;s also information that's > readily available when InputArg/OutputArgs are being constructed. In your > case: > > CCIf<"SourceTy->isPointerTy()", CCAssignToReg<[P1, P2]>>; > > I've got a patch which implements it for ARM and X86 (though not HFAs using > the features yet, I'm still musing on the best interface to present there > -- "HFA* byval" for target simplicity or "HFA" for user simplicity), I'll > see if I can clean it up for other targets and send it for comparison. Here's the patch I was ta...

...er arguments. When deciding whether to pass an argument as a homogeneous aggregate, one of the criteria is that the entire aggregate has to fit into the remaining unused argument registers, right? I tend to think that if every front-end has to implement the entire VFP PCS to decide how to pass an HFA, something has gone wrong. So I've come to the conclusion that the real flaw is LLVM not exposing enough information to the target-dependent backend code for it to do the right thing. By the time the target is involved, all that remains of any composite type is: * The fields completely separa...

...Ready.) Online/Offline : Online. no entries. The two that say "done" are the jobs which appear as paused in the windows printer queue. The only way I can remove them without restarting windows machines is to manually delete the queue files from /var/spool/RICOH which are cfA*, dfA*, and hfA*. There may be a more elegant way to delete them via command line, but I don't know it. [root@mi RICOH]# ll /var/spool/lpd/RICOH/ total 6396 -rw------- 1 lp lp 171 Jul 24 09:53 cfA521mi.windermere.com -rw------- 1 lp lp 177 Jul 21 12:43 cfA889mi.winderm...

...-Operating-System: 'Linux localhost.localdomain 2.2.9-27mdk #1 Mon Jan 24 15:49:34 CET 2000 i686 unknown' X-Geek: GIT d s+:- a-- C++ UL P+ L++ E W N+ w- PS+ PE++ PGP t-- X-- R- tv- b+ D+ G e h-- r- z? Lines: 30 X-KJONCA-Clamav-Status: No jd;fladflsd;lc dfgn;sdhgfad abffhahgl fadn;al sdfnad;hfa fna;lhfla -- shfkah --8<---------------cut here---------------end--------------->8--- When I try to dovecot-lda < message.txt (for sieve refiltering) I got segmentation fault. Does it is bug in lda, or message does not keep standards? KJ -- http://modnebzdury.wordpress.com/2009/10/0...

...d function writeRaster{raster} to write this rasterLayer into every format it supports, and ArcGIS respond to them in three different ways, but none of them works. I wonder why it happens and if there is someway to solve this problem? ArcGIS respond type: 1. Show strange values GTiff, HFA 2. Show even values in whole raster IDRISI, ascii, EHdr 3. Cannot recognize files CDF, raster, SAGA, CDF , ENVI Yuanjing Xu PhD. Student of Biodiversity Conservation [[alternative HTML version deleted]]

Hi all, I think that ABI of LLVM IR level is different from ABI on real architecture such as ARM or x86. ABI of LLVM IR level doesn't consider about register usage. It just describes parameters and padding information related to alignment of parameters. As Anton mentioned, LLVM have expressed ABI information on bitcode using front-end. If someone wants to maintain information from high level

Tim, > Opinions, anyone? (Hint hint). I think here stuff should be thought of from different points. While providing source type for argument might be beneficial, it might cause moving the code from frontend to backend. Consider e.g. passing struct by value including crazy padding inside. The ABI might specify that padding should be removed and struct is passed field-by-field. Also, note that

Good day oh technical ones . I was running Samba 4 (client only, not using it as a DC so effectively running Samba 3 code from the Samba 4 tree) and, other than a little "Gotcha!" regarding decoding Kerberos PACs, it was all working perfectly. Then recently I had to upgrade, to "4.2.0pre1-GIT-b505111" (I had to upgrade the OS on the server