aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/gallivm/lp_bld_init.c
Commit message (Collapse)AuthorAgeFilesLines
* gallivm: add cache interface to mcjitDave Airlie2020-06-111-0/+1
| | | | | | | | | | MCJIT uses an ObjectCache object to implement the cache, this creates and instances of it and adds it to the MCJIT instances, it stores the cached object for later use by the outer layers. Reviewed-by: Roland Scheidegger <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5049>
* gallivm: skip operations if we have a cached object.Dave Airlie2020-06-111-0/+5
| | | | | | | | If the object is loaded from the cache, a bunch of gallivm/llvm interactions can be skipped. Reviewed-by: Roland Scheidegger <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5049>
* gallivm: add support for a cache objectDave Airlie2020-06-111-4/+10
| | | | | | | | This plumbs the cache object into the gallivm API, nothing uses it yet. Reviewed-by: Roland Scheidegger <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5049>
* gallivm: rework debug printf hook to use global mapping.Dave Airlie2020-06-111-0/+3
| | | | | | | | | Cached shaders require relinking, so hardcoding the pointer can't work. This switches out the printf code to use new proper API. Reviewed-by: Roland Scheidegger <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5049>
* llvmpipe: move coroutines out of noopt caseDave Airlie2020-06-041-3/+3
| | | | | | | | | | | | | | | | | the virgl CI code was using the noopt path and crashing with a wierd can't select llvm.coro.subfn.addr error, turns out we have to call the cleanup pass no matter what. This enable a lot more virgl gles31 passes, but we have to disable tessellation shaders as now they executed, they crash due to missing OES_gpu_shader5, I should try and reenable them when llvmpipe is further along Fixes: d32690b43c91d ("gallivm: add coroutine pass manager support") Reviewed-by: Roland Scheidegger <[email protected]> Acked-by: Elie Tournier <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5320>
* gallium/gallivm: Remove workaround disabling AVX code for newer CPUsJan Zielinski2020-03-231-9/+3
| | | | | | | | | | | | The change enables using full 256-bit AVX and AVX2 instructions on newer platforms. Reviewed-by: Alok Hota <[email protected]> Reviewed-by: Adam Jackson <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4225> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4225>
* gallivm/s390: fix pass init order on s390 with llvm 8 (v2)Dave Airlie2020-02-151-2/+3
| | | | | | | | | | | llvm 8 has some missing pass dependencies, fix the s390 case as well. v2: add ARM also (Michel) Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Adam Jackson <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3805>
* gallium/swr: Fix various asserts and security issuesJan Zielinski2020-02-051-1/+2
| | | | | | | | | | To improve the robustness of the code, we want to better detect issues in testing (using asserts) and use more secure techniques. Reviewed-by: Krzysztof Raszkowski <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3710> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3710>
* util: rename PIPE_ARCH_*_ENDIAN to UTIL_ARCH_*_ENDIANDylan Baker2019-11-051-1/+1
| | | | | | | | | | | As requested by Tim. This was generated with: grep 'PIPE_ARCH_.*_ENDIAN' -rIl | xargs sed -ie 's@PIPE_ARCH_\(.*\)_ENDIAN@UTIL_ARCH_\1_ENDIAN@'g v2: - add this patch Reviewed-by: Eric Engestrom <[email protected]>
* util/u_endian: set PIPE_ARCH_*_ENDIAN to 1Dylan Baker2019-11-051-1/+1
| | | | | | | | | | | | This will allow it to be used as a drop in replacement for _mesa_little_endian in a number of cases. v2: - Always define PIPE_ARCH_LITTLE_ENDIAN and PIPE_ARCH_BIG_ENDIAN, define the one that reflects the host system to 1 and the other to 0 - replace all uses of #ifdef, #ifndef, and #if defined() with #if and #if ! with PIPE_ARCH_*_ENDIAN Reviewed-by: Eric Engestrom <[email protected]>
* gallivm: fix coroutines on aarch64 with llvm 8Dave Airlie2019-10-111-0/+6
| | | | | | | | | | | | | | | The coroutine split pass is missing a dependency before LLVM 9.0, and fails to initialise properly if the CallGraphWrapperPass hasn't be initialised earlier (x86 does it due to some of it's passes requiring it). This is a workaround for llvm 8 (coroutines are only supported in 8 and higher). It adds another pass that has a dependency on the pass the coroutines split requires. This pass shouldn't have any raal effects. Fixes: d32690b43c9 (gallivm: add coroutine pass manager support) Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: Require LLVM >= 3.9Adam Jackson2019-09-111-5/+0
| | | | | | | | To go any further than this would be to break the current version of Android. Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallium: Require LLVM >= 3.7Adam Jackson2019-09-111-3/+1
| | | | | Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallium: Require LLVM >= 3.6Adam Jackson2019-09-111-112/+66
| | | | | Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallium: Require LLVM >= 3.5Adam Jackson2019-09-111-1/+1
| | | | | | | Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> [ Michel Dänzer: Dropped jessie line from debian-install.sh again ]
* gallium: Require LLVM >= 3.4Adam Jackson2019-09-111-1/+1
| | | | | Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: drop LLVM<3.3 code paths as no build system allows thatEric Engestrom2019-09-061-2/+2
| | | | | Suggested-by: Michel Dänzer <[email protected]> Signed-off-by: Eric Engestrom <[email protected]>
* gallivm: replace more complex 3.x version check with LLVM_VERSION_MAJOR/MINOREric Engestrom2019-09-061-5/+5
| | | | | Signed-off-by: Eric Engestrom <[email protected]> Acked-by: Michel Dänzer <[email protected]>
* gallivm: replace major llvm version checks with LLVM_VERSION_MAJOREric Engestrom2019-09-061-1/+2
| | | | | Signed-off-by: Eric Engestrom <[email protected]> Acked-by: Michel Dänzer <[email protected]>
* gallivm: add coroutine pass manager supportDave Airlie2019-09-041-1/+26
| | | | | | | coroutines require a proper pass manager, so add the passes to the correct places Reviewed-by: Roland Scheidegger <[email protected]>
* util: use standard name for snprintf()Eric Engestrom2019-07-191-2/+2
| | | | | | | Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* Add no_aos_sampling GALLIVM_PERF optionDominik Drees2019-04-171-0/+1
| | | | | This forces using general sampling and should improve precision and performance in some cases.
* gallivm: Make it possible to disable some optimization shortcuts in release ↵Gert Wollny2018-10-061-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | builds For testing it is of interest that all tests of dEQP pass, e.g. to test virglrenderer on a host only providing software rendering like in a CI. Hence make it possible to disable certain optimizations that make tests fail. While we are there also add some documentation to the flags to make it clear that this is opt-out. Setting the environment variable "GALLIVM_PERF=no_filter_hacks" can be used to make the following tests pass in release mode: dEQP-GLES2.functional.texture.mipmap.2d.affine.*_linear_* dEQP-GLES2.functional.texture.mipmap.cube.generate.* dEQP-GLES2.functional.texture.vertex.2d.filtering.*_mipmap_linear_* dEQP-GLES2.functional.texture.vertex.2d.wrap.* Related: https://bugs.freedesktop.org/show_bug.cgi?id=94957 v2: rename optimization disabling flag to 'safemath' and also move the nopt flag to the perf flags. v3: rename flag "safemath" to "no_filter_hacks" since safemath is usually associated with floating point operations (Roland) Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: dump bitcode before optimizationRoland Scheidegger2018-04-241-13/+20
| | | | | | | | | | | | | | | | | | If we dump the bitcode for off-line debug purposes, we really want the pre-optimized bitcode, otherwise it's useless in identifying problems with IR optimization (if you have a shader which takes an hour to do IR optimization, it's also nice you don't have to wait that hour...). Also, print out the function passes for opt which correspond to what was used for jit compilation (and also the opt level for codegen). Using opt/llc this way should then pretty much mimic what was done for jit. (When specifying something like -time-passes -debug-pass=[Structure|Arguments] (for either opt or llc) that also gives very useful information in which passes all the time was spent, and which passes are really run along with the order - llvm will add passes due to dependencies on its own, and of course -O2 for llc comes with a ~100 pass list.) Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: (trivial) do division by 1000 with int64Roland Scheidegger2018-04-241-1/+1
| | | | | | | Conversion to int can otherwise overflow if compile times are over ~71min. (Yes this can happen...) Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: remove LICM passRoland Scheidegger2018-04-241-1/+9
| | | | | | | | | | | | | | LICM is simply too expensive, even though it presumably can help quite a bit in some cases. It was definitely cheaper in llvm 3.3, though as far as I can tell with llvm 3.3 it failed to do anything in most cases. early-cse also actually seems to cause licm to be able to move things when it previously couldn't, which causes noticeable compile time increases. There's more loop passes in llvm, but I'm not sure which ones are helpful, and I couldn't find anything which would roughly do what the old licm in llvm 3.3 did, so ditch it. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: add early cse passRoland Scheidegger2018-04-241-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This pass is quite cheap, and can simplify the IR quite a bit for our generated IR. In particular on a variety of shaders I've found the time saved by other passes due to the simplified IR more than makes up for the cost of this pass, and on top of that the end result is actually better. The only downside I've found is this enables the LICM pass to move some things out of the main shader loop (in the case I've seen, instanced vertex fetch (which is constant within the jit shader) plus the derived instructions in the shader) which it couldn't do before for some reason. This would actually be desirable but can increase compile time considerably (licm seems to have considerable cost when it actually can move things out of loops, due to alias analysis). But blaming early cse for this seems inappropriate. (Note that the first two sroa / earlycse passes are similar to what a standard llvm opt -O1/-O2 pipeline would do, albeit this has some more passes even before but I don't think they'd do much for us.) It also in particular helps some crazy shader used for driver verification (don't ask...) a lot (about factor of 6 faster in compile time) (due to simplfiying the ir before LICM is run). While here, also move licm behind simplifycfg. For some shaders there seems to be very significant compile time gains (we've seen a factor of 10000 albeit that was a really crazy shader you'd certainly never see in a real app), beause LICM is quite expensive and there's cases where running simplifycfg (along with sroa and early-cse) before licm reduces IR complexity significantly. (I'm not entirely sure if it would make sense to also run it afterwards.) Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Fix include for LLVMAddPromoteMemoryToRegisterPassMike Lothian2018-04-021-0/+3
| | | | | | | | | Include llvm-c/Transforms/Utils.h with the newest LLVM 7 Signed-of-by: Mike Lothian <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]> Tested-by: Dieter Nützel <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* util: move os_time.[ch] to src/utilNicolai Hähnle2017-11-091-1/+1
| | | | Reviewed-by: Marek Olšák <[email protected]>
* gallivm: fix typo in debug_printf messageBen Crocker2017-10-051-1/+1
| | | | | | | | | | In gallivm_compile_module, fix a typo in the debug_printf("Invoke as \"llc ..." message. Cc: "17.2" <[email protected]> Signed-off-by: Ben Crocker <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: Make sure module has the correct data layout when pass manager runsTom Stellard2017-05-181-16/+18
| | | | | | | | | | | | | | | | | | | The datalayout for modules was purposely not being set in order to work around the fact that the ExecutionEngine requires that the module's datalayout matches the datalayout of the TargetMachine that the ExecutionEngine is using. When the pass manager runs on a module with no datalayout, it uses the default datalayout which is little-endian. This causes problems on big-endian targets, because some optimizations that are legal on little-endian or illegal on big-endian. To resolve this, we set the datalayout prior to running the pass manager, and then clear it before creating the ExectionEngine. This patch fixes a lot of piglit tests on big-endian ppc64. Cc: [email protected]
* gallivm: Improve debug output (V2)Ben Crocker2017-02-201-1/+4
| | | | | | | | | | | | | | | Improve debug output from gallivm_compile_module and lp_build_create_jit_compiler_for_module, printing the -mcpu and -mattr options passed to LLC. V2: enclose MAttrs debug_printf block and llc -mcpu debug_printf in "if (gallivm_debug & <flags>)..." Signed-off-by: Ben Crocker <[email protected]> Cc: 12.0 13.0 17.0 <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> (v2) [Emil Velikov: rebase] Signed-off-by: Emil Velikov <[email protected]>
* gallivm: Cleanup USE_MCJIT.Jose Fonseca2017-01-181-10/+25
| | | | | | | Split USE_MCJIT macro dual nature into a separate constant time define and a run-time variable. Reviewed-by: Emil Velikov <[email protected]>
* gallivm: print out time for jitting functions with GALLIVM_DEBUG=perfRoland Scheidegger2016-10-191-0/+11
| | | | | | | | Compilation to actual machine code can easily take as much time as the optimization passes on the IR if not more, so print this out too. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Basic AVX2 support.José Fonseca2016-10-041-0/+5
| | | | | | v2: pblendb -> pblendvb Reviewed-by: Roland Scheidegger <[email protected]>
* util,gallivm: Explicitly enable/disable fma attribute.Jose Fonseca2016-06-101-0/+2
| | | | | | | | | | As suggested by Roland Scheidegger. Use the same logic as f16c, since fma requires VEX encoding. But disable FMA on LLVM 3.3 without MCJIT. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: improve dumping of bitcodeRoland Scheidegger2016-05-111-4/+8
| | | | | | | | | Use GALLIVM_DEBUG=dumpbc for dumping of modules as bitcode. Instead of a fixed llvmpipe.bc name, use ir_<modulename>.bc so multiple modules can be dumped (albeit it might still overwrite previous modules, particularly the modules from draw tend to always have the same name). Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Remove lp_get_module_id.Jose Fonseca2016-04-191-1/+14
| | | | | | Just keep a copy of the module_name in gallivm. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: Make MCJIT a runtime option.Jose Fonseca2016-04-191-75/+72
| | | | | | | | | | | | | On the LLVM versions that support it, so we can easily switch between MCJIT/old-jit for testing. The new option is GALLIVM_MCJIT. Unfortunately setting GALLIVM_MCJIT=1 for LLVM 3.3 or 3.4 causes segfault, both on Linux and Windows. I'm almost certain this used to work, so there probably is a regression somewhere. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: Add debug option to force SSE2.Jose Fonseca2016-04-031-11/+14
| | | | | | For simulating less capable machines. Reviewed-by: Roland Scheidegger <[email protected]>
* Handle removal of LLVMAddTargetData in SVN revision 260919Matthew Dawson2016-02-161-0/+2
| | | | | | | | | | | | | | | | | | | LLVM removed LLVMAddTargetData for the 3.9 release in r260919. For the two places in mesa where this is called, only enable the lines when compiling for less then 3.9. For the radeon driver, I'm not sure how to check if any other LLVM calls need to be adjusted. I think since the target data used is extracted from the LLVMModule, it isn't necessary to pass it back to LLVM again. The code does compile, and at least for radeonsi does run OpenGL games. [ Michel Dänzer: Move #if closer to LLVMAddTargetData in lp_bld_init.c, and add HAVE_LLVM < 0x0309 guards around now unused occurrences of TD and data_layout ] Signed-off-by: Matthew Dawson <[email protected]> Reviewed-and-Tested-by: Michel Dänzer <[email protected]>
* gallivm: disable f16c when not using AVXRoland Scheidegger2015-10-261-0/+3
| | | | | | | | | | | | | | | | | f16c intrinsic can only be emitted when AVX is used. So when we disable AVX due to forcing 128bit vectors we must not use this intrinsic (depending on llvm version, this worked previously because llvm used AVX even when we didn't tell it to, however I've seen this fail with llvm 3.3 since 718249843b915decf8fccec92e466ac1a6219934 which seems to have the side effect of disabling avx in llvm albeit it only touches sse flags really, but with ea421e919ae6e72e1319fb205c42a6fb53ca2f82 it's now really disabled). Albeit being able to use AVX with 128bit vectors also would have its uses, the code as is really was meant to emulate jit code creation for less capable cpus. v2: add some (ifdefed out) missing de-featuring options for simulating less capable cpus. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Initialize LLVM Modules's DataLayout to an empty string.Tom Stellard2015-07-201-5/+23
| | | | | | | | | | | | | | This fixes crashes in llvmpipe with LLVM 3.8 and also some piglit tests on radeonsi that use the draw module. This is just a temporary solution. The correct solution will require creating a TargetMachine during gallivm initialization and pulling the DataLayout from there. This will be a somewhat invasive change, and it will need to be validatated on multiple LLVM versions. https://llvm.org/bugs/show_bug.cgi?id=24172 Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: Disable frame pointer omission on LLVM 3.7.Jose Fonseca2015-05-291-0/+10
| | | | Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: use llvm function calls for texturing instead of inliningRoland Scheidegger2015-03-271-8/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are issues with inlining everything, most notably llvm will use much more memory (and be slower) when compiling. Ideally we'd probably use functions for shader functions too but texture sampling usually is responsible for quite some IR (it can easily reach 80% of total IR instructions) so this seems like a good start. This still generates a different function for all different combinations just like before, however it is possible llvm is missing some optimization opportunities - it is believed though such opportunities should be somewhat rare, but at least for now it can still be switched off (at compile time only). It should probably make compiled code also smaller because the same function should be used for different variants in the same module (so for the opaque/partial or linear/elts variants). No piglit change (though it does indeed speed up unrealistic tests like fp-indirections2 by a factor of 30 or so). Has a small negative performance impact in openarena - I suspect this could be fixed by running some IPO passes (despite the private linkage, llvm right now does NO optimization at all wrt anything going past the call, even if there's just one caller - so things like values stored before the call and then always written by the function etc. will not be optimized away, nor will dead arguments (which we mostly shouldn't have) be eliminated, always constant arguments promoted etc.). v2: use proper return values instead of pointer function arguments. llvm supports aggregate return values, which do wonders here eliminating unnecessary stack variables - everything in fact will be returned in registers even without any IPO optimizations. It makes the code simpler too. With this I could not measure a peformance impact in openarena any longer (though since there's still no constant value propagation etc. into the tex functions this does not mean it couldn't have a negative impact elsewhere). v3: fix some minor issues suggested by Jose, and do disassembly (and the profiling) without hacks. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: fix uninitialized-variable warningsMarek Olšák2015-02-211-1/+1
| | | | Reviewed-by: Brian Paul <[email protected]>
* gallium: Replace u_simple_list.h with util/simple_list.hEric Anholt2015-01-281-1/+1
| | | | | | | The code was exactly the same, except util/ has c++ guards and a struct simple_node declaration. Reviewed-by: Marek Olšák <[email protected]>
* gallivm: Properly update for removal of JITMemoryManager in LLVM 3.6.José Fonseca2014-10-231-11/+0
| | | | | | | | | | | | | | | | | | JITMemoryManager was removed in LLVM 3.6, and replaced by its base class RTDyldMemoryManager. This change fixes our JIT memory managers specializations to derive from RTDyldMemoryManager in LLVM 3.6 instead of JITMemoryManager. This enables llvmpipe to run with LLVM 3.6. However, lp_free_generated_code is basically a no-op because there are not enough hook points in RTDyldMemoryManager to track and free the code of a module. In other words, with MCJIT, code once created, stays forever allocated until process destruction. This is not speicfic to LLVM 3.6 -- it will happen whenever MCJIT is used regardless of version. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm,llvmpipe,clover: Bump required LLVM version to 3.3.José Fonseca2014-10-231-35/+2
| | | | | | | | | | | | | | We'll need to update gallivm for the interface changes in LLVM 3.6, and the fewer the number of older LLVM versions we support the less hairy that will be. As consequence HAVE_AVX define can disappear. (Note HAVE_AVX meant whether LLVM version supports AVX or not. Runtime support for AVX is always checked and enforced independently.) Verified llvmpipe builds and runs with with LLVM 3.3, 3.4, and 3.5. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: Fix build for LLVM 3.2Mathias Fröhlich2014-10-011-3/+1
| | | | | | | | | | | | Do not rely on LLVMMCJITMemoryManagerRef being available. The c binding to the memory manager objects only appeared on llvm-3.4. The change is based on an initial patch of Brian Paul. Reviewed-by: Brian Paul <[email protected]> Tested-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Mathias Froehlich <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 16:38:44 +0000