similar to: [LLVMdev] updated code size comparison

On 01/20/2010 05:54 PM, John Regehr wrote: > Hi folks, > > I've posted an updated code size comparison between LLVM, GCC, and > others here: > > http://embed.cs.utah.edu/embarrassing/ > > New in this version: > > - much larger collection of harvested functions: more than 360,000 > > - bug fixes and UI improvements > > - added the x86 Open64

On Wed, Jan 20, 2010 at 7:54 AM, John Regehr <regehr at cs.utah.edu> wrote: > Hi folks, > > I've posted an updated code size comparison between LLVM, GCC, and > others here: > >   http://embed.cs.utah.edu/embarrassing/ > > New in this version: > > - much larger collection of harvested functions: more than 360,000 > > - bug fixes and UI improvements

> I started looking through the llvm-gcc vs. clang comparisons, and > noticed that in > http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/A9/A9AB5AE7.c > , size_t is declared incorrectly. Any idea how that might have > happened? Hi Eli, Thanks for pointing this out, I'll look into this tonight. However I can give you the quick generic answer right now (of course

A few random observations: 1. Clang could do better with large but boring switches like this: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/E8/E88C5111.shtml Performance of clang's output will be fine but this is a major code size lose. 2. Destruction of stupid loops is incomplete, sometimes due to phase ordering problems:

Hi Torok- > Could you also add a main() for each of these files, and do > a very simple test that the optimized functions actually work? Unfortunately, testing isolated C functions is much harder than just passing them random data! Consider this function: int foo (int x, int y) { return x+y; } The behavior of foo() is undefined when x+y overflows. If course it is trivial to come

>> Repetitive code with lots of bitwise operations is compiled by LLVM into >> much larger code than the other compilers: >> >> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/ED/ED37DAF5.shtml >> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/1F/1F4003C7.shtml >> >> Note that this is straight-line code, so LLVM's output will

> Umm, can you find one that isn't a popcount implementation? Ok. MMX psadbw instruction: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/CE/CE3DA132.shtml Position of first set bit: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/1F/1F4003C7.shtml Log2 floor: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/83/837A80E9.shtml Pixel format

On Tue, Jan 26, 2010 at 5:55 PM, John Regehr <regehr at cs.utah.edu> wrote: >>> Repetitive code with lots of bitwise operations is compiled by LLVM into >>> much larger code than the other compilers: >>> >>> >>> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/ED/ED37DAF5.shtml >>> >>>

On Tue, Jan 26, 2010 at 12:36 PM, John Regehr <regehr at cs.utah.edu> wrote: > 2. > Sometimes not: > > http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/EC/ECC74C0C.shtml The primary issue here is that scalar evolution doesn't know how to deal with loops using "sle" for the exit condition. Shouldn't be too hard to fix now that we have overflow flags

To: Everyone That Ordered A T-Shirt Or Wants One If you want a T-Shirt but haven't ordered yet, you have until the 4pm PST tomorrow (24 hours from now) to let me know or alter your existing order. The T-Shirt is described this way: 437 JERZEES 50/50 Spot Shield Polo 50/50 cotton/poly blend, 5.6 oz. Treated with Spot Shield, most water and oil based stains bead up and roll off. 2-button

On Wed, Jan 20, 2010 at 12:05 PM, John Regehr <regehr at cs.utah.edu> wrote: >> I started looking through the llvm-gcc vs. clang comparisons, and >> noticed that in >> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/A9/A9AB5AE7.c >> , size_t is declared incorrectly.  Any idea how that might have >> happened? > > Hi Eli, > > Thanks for

Is there any possibility to get high resolution plots in a windows xp system? I tried it with the device function png(filename = "c:/r/highresplot%d.png",pointsize=12, res=900) but when I try to set: width = 480, height = 480 or pointsize = 12, the text is not scaled in the same way as the plots. with regards Knut Krueger http://www.biostatistic.de

Just a warning to dovecot listmembers. The list is being harvested. test3943395 is a unique address I created only for communication to the dovecot list. The following spam came from: Received: from dial-dynamic-62-69-52-187.surfdial.murphx.net (dial-dynamic-62-69-52-187.surfdial.murphx.net [62.69.52.187]) by sasami.anime.net (8.11.6/8.11.6) with SMTP id j7FLxtv03775 for

Here's a thought I just thunk, folks: some scum, apparently in eastern Europe, has harvested my email, and is using it in the Reply-To: in its spamming efforts. Now, I realize that some mails go out from noreply, but other than that, is there a good reason why a mailserver would not be configured to send delivery failure to *both* Reply-To and From? mark

Hello, is it possible to login into a DomU (Windows) without beeing logged in in the Dom0 on the same PC where Xen runs? So I want to have something like the Windows login screen on e. g. tty2 so I do not need to login twice (first in Dom0 and the second one in the DomU). Thanks for help, Markus _______________________________________________ Xen-users mailing list

Not to stir the pot, but I notice my email address has recently been harvested from this list for spamming purposes. This email address is unique and not used for anything else. I'd distinguish this from spam sent to the mailing list itself, which is obviously different. Is there anything further that could be done to prevent this? -- Dave

Roger Marquis wrote: > [snip] > >It takes all of 2 seconds to generate a ssh 2 new session on a >500Mhz cpu (causing less than 20% utilization). Considering that >99% of even the most heavily loaded servers have more than enough >cpu for this task I don't really see it as an issue. > >Also, by generating a different key for each session you get better >entropy,

> Password schemes: HMAC-MD5, RPA, SKEY, PLAIN-MD4, LANMAN, NTLM, SMD5 The web is flooded with plain text passwords and hashed passwords harvested from hacked servers. Dovecot stores passwords with the same scheme used for client authentication. Therefore, we use crammd5/hmac-md5. It does not look like much, but is better than plaintext. As md5 is about to go, and I have no intention to

Hi folks, first of all thanks for Dovecot, I appreciate it a lot. On one of our servers, we experience regular tries to brute force logins, probably based on harvested mail addresses. Now I wonder if dovecot has or could in future have some mechanism to blacklist remote IP addresses after a configurable number of failures to login to any account. Blacklisted IPs could simply be disconnected

It appears that someone has harvested email addresses from the S-news or one of the R lists and is sending out viruses. The mail does not come from the lists, but appears to come from people on these lists. (Closer examination of the headers indicates that it does not really come from the person indicated in the "from" field.) The mail is probably directed to people on these lists as