Rolled out release v0.3, started working on hardware loops.
With CI builds there's a problem that all free CI providers known to me have some limitations, either time or hdd space. And LLVM takes hell lot of time and space. So either I'll set up my own CI, or I'll try asking Travis or Semaphore to give me more resources, I heard they usually cooperate if the project is open source.
Statistics: Posted by upcFrost — Mon Mar 19, 2018 7:44 pm
]]>
]]>
On the compiler side - working on vectorization, or strd/ldrd to be precise, plus i64/f64 support. Atm most tests build fine, and actually arithmetic runs a bit faster than on GCC (not much, as i'm still using precompiled libs from gcc bundle). I want to fix matmul-16 test which fails on memory mapping (sections overlap) before moving on.
Another big question is CI and distribution. Travis has build time limitation of 1 hour, which is not enough to build full LLVM stack, and ccache size of 512 mb, which is not enough to use ccache with LLVM build. Semaphore has disk quote, which is also too small to fit the build. Will try to look for solution, or maybe i'll just mail Semaphore or Travis and ask them to raise quote for my build (iirc they're ok doing it for FOSS projects
)Statistics: Posted by upcFrost — Mon Sep 11, 2017 8:53 pm
]]>
Gregg, about volatile access - that's exactly as @jar said. It is possible to implement (basically skipping one "if-then" case), but as it might, and it will in some cases, break the code.
Still, in some cases it can improve performance quite a bit. I'm planning to make additional flag to allow it, but it will be set to false by default.
So the default behavior is not to touch volatile ldr/str at all, just as in spec
Statistics: Posted by upcFrost — Tue Jul 11, 2017 3:50 pm
]]>
]]>
]]>
]]>
]]>
Statistics: Posted by sebraa — Thu Jul 06, 2017 3:15 pm
]]>
]]>
]]>
]]>
]]>
]]>
]]>