[Mesa-dev] Bug in 17.1.0-rc4 source packaging for swr?

Rowley, Timothy O timothy.o.rowley at intel.com
Fri May 19 16:46:04 UTC 2017


On May 19, 2017, at 10:26 AM, Emil Velikov <emil.l.velikov at gmail.com<mailto:emil.l.velikov at gmail.com>> wrote:

On 19 May 2017 at 13:11, Chuck Atkins <chuck.atkins at kitware.com<mailto:chuck.atkins at kitware.com>> wrote:
Would it be feasible for packaging purposes to generate multiple headers,
i.e. gen_builder._llvm38.hpp, gen_builder_llvm39.hpp,
gen_builder_llvm40.hpp, etc. and then have gen_builder.hpp be a stub that
just has something like:

#include <llvm.h>
#if llvm_version >= 4.0
#include "gen_builder_llvm40.hpp"
#elif llvm_version >= 3.9
#include "gen_builder_llvm39.hpp"
#elif llvm_version >= 3.8
#include "gen_builder_llvm38.hpp"
#else
#error llvm version >= 3.8 is required
#elif

Idea sounds ok, but has a few drawbacks:
- creating all the files at the same time would be quite picky/hard
- shipping only one file solves the issue only for some people

We need to figure out where to put the burden of keeping gen_builder up to date:
  - swr developers take care of updating new versions as needed
  - build system + release maintainer generates a lower common denominator version

The original idea by Tim sounds OK imho and I'm actually giving it a try.

Are you referring to using a llvm-3.9 generated version?  Did you envision me checking that in a gen_builder.h file, or removing the logic that omitted it from the tarball and somehow enforcing that a packaging build needs llvm-3.9?

FWIW the diff between 3.9 and 4.0 seems quite trivial - see below.
It should be possible to update the python scripts to handle most/all of those.
Perhaps we can have this as a long term solution?

At this point llvm seems to be stable in just having intrinsics being added; for a while there was some churn.  Unless/until the swr driver/rasterizer starts to take advantage of new llvm intrinsics, we should be fine using the 3.9 version.

-Tim


-Emil

@@ -86,6 +86,11 @@
   return IRB()->CreateLifetimeEnd(Ptr, Size);
}

+CallInst* INVARIANT_START(Value *Ptr, ConstantInt *Size = nullptr)
+{
+    return IRB()->CreateInvariantStart(Ptr, Size);
+}
+
CallInst* MASKED_LOAD(Value *Ptr, unsigned Align, Value *Mask, Value
*PassThru = nullptr, const Twine &Name = "")
{
   return IRB()->CreateMaskedLoad(Ptr, Align, Mask, PassThru, Name);
@@ -176,6 +181,11 @@
   return IRB()->CreateCondBr(Cond, True, False, BranchWeights, Unpredictable);
}

+BranchInst* COND_BR(Value *Cond, BasicBlock *True, BasicBlock *False,
Instruction *MDSrc)
+{
+    return IRB()->CreateCondBr(Cond, True, False, MDSrc);
+}
+
SwitchInst* SWITCH(Value *V, BasicBlock *Dest, unsigned NumCases = 10,
MDNode *BranchWeights = nullptr, MDNode *Unpredictable = nullptr)
{
   return IRB()->CreateSwitch(V, Dest, NumCases, BranchWeights, Unpredictable);
@@ -866,7 +876,7 @@
   return IRB()->CreateCall(Callee, Args, Name, FPMathTag);
}

-CallInst* CALLA(llvm::FunctionType *FTy, Value *Callee,
ArrayRef<Value *> Args, const Twine &Name = "", MDNode *FPMathTag =
nullptr)
+CallInst* CALLA(FunctionType *FTy, Value *Callee, ArrayRef<Value *>
Args, const Twine &Name = "", MDNode *FPMathTag = nullptr)
{
   return IRB()->CreateCall(FTy, Callee, Args, Name, FPMathTag);
}

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170519/b8c1469e/attachment-0001.html>


More information about the mesa-dev mailing list