search for: reusu

...hat the reg-allocator and alias analysis (assuming this exists in libjit) is not the best. I wonder if llvm will have a problem. If I make the appropriate llvm calls to redundandly load an integer of a pointer several times (e.g. (goo == *a) .... .... (foo == *a)), will llvm make every effort to reusue the temp created to store *a initially in the second reference? I tried this out with the llvm demo, and the C code generated automatically created a temp for the first load, and then reused that temp in the secondary reference. I however would not be making such calls - I instead would probably...

...and an external host. Two hosts were connected through 40gb mlx4 cards. With both busy_poll and busy_read are set to 50 in guest, 1 byte netperf tcp_rr shows 127% improvement: transaction rate was increased from 8353.33 to 18966.87. Changes from V2: - Avoid introducing new states and spinlocks by reusuing the NAPI state - Fix the budget calculation in virtnet_poll() - Drop patch 1/3 from V2 since it was useless Changes from V1: - split the patch info smaller ones - add more details about test setup/configuration Jason Wang (2): virtio-net: introduce virtnet_receive() virtio-net: rx busy p...

...and an external host. Two hosts were connected through 40gb mlx4 cards. With both busy_poll and busy_read are set to 50 in guest, 1 byte netperf tcp_rr shows 127% improvement: transaction rate was increased from 8353.33 to 18966.87. Changes from V2: - Avoid introducing new states and spinlocks by reusuing the NAPI state - Fix the budget calculation in virtnet_poll() - Drop patch 1/3 from V2 since it was useless Changes from V1: - split the patch info smaller ones - add more details about test setup/configuration Jason Wang (2): virtio-net: introduce virtnet_receive() virtio-net: rx busy p...

...r and alias analysis (assuming > this exists in libjit) is not the best.  I wonder if llvm will have a > problem.  If I make the appropriate llvm calls to redundandly load an > integer of a pointer several times (e.g. (goo == *a) .... ....  (foo == > *a)), will llvm make every effort to reusue the temp created to store *a > initially in the second reference?  I tried this out with the llvm demo, and > the C code generated automatically created a temp for the first load, and > then reused that temp in the secondary reference.  I however would not be > making such calls - I in...

...(assuming > > this exists in libjit) is not the best. I wonder if llvm will have a > > problem. If I make the appropriate llvm calls to redundandly load an > > integer of a pointer several times (e.g. (goo == *a) .... .... (foo == > > *a)), will llvm make every effort to reusue the temp created to store *a > > initially in the second reference? I tried this out with the llvm demo, and > > the C code generated automatically created a temp for the first load, and > > then reused that temp in the secondary reference. I however would not be > > maki...

...(assuming > > this exists in libjit) is not the best. I wonder if llvm will have a > > problem. If I make the appropriate llvm calls to redundandly load an > > integer of a pointer several times (e.g. (goo == *a) .... .... (foo == > > *a)), will llvm make every effort to reusue the temp created to store *a > > initially in the second reference? I tried this out with the llvm demo, and > > the C code generated automatically created a temp for the first load, and > > then reused that temp in the secondary reference. I however would not be > > maki...

...gt; > this exists in libjit) is not the best.  I wonder if llvm will have a >> > problem.  If I make the appropriate llvm calls to redundandly load an >> > integer of a pointer several times (e.g. (goo == *a) .... ....  (foo == >> > *a)), will llvm make every effort to reusue the temp created to store *a >> > initially in the second reference?  I tried this out with the llvm demo, >> > and >> > the C code generated automatically created a temp for the first load, >> > and >> > then reused that temp in the secondary reference...