[Mesa-dev] [PATCH 1/2] radeonsi: Cache LLVMTargetMachine object in si_screen

[Michel Dänzer]

On 07.01.2015 10:10, Michel Dänzer wrote:
> On 07.01.2015 06:33, Tom Stellard wrote:
>> On Wed, Dec 24, 2014 at 12:48:31PM +0900, Michel Dänzer wrote:
>>> On 24.12.2014 02:49, Tom Stellard wrote:
>>>> Rather than building a new one every compile.  This should reduce some
>>>> of the overhead of compiling shaders.
>>>
>>> Thanks, though unfortunately it doesn't seem to make much difference for
>>> piglit for me.
>>>
>>>
>>>> One consequence of this change is that we lose the MachineInstrs dumps
>>>> when dumping the shaders via R600_DEBUG.  The LLVM IR and assembly is
>>>> still dumped, and if you still want to see the MachineInstr dump, you
>>>> can run the dumped LLVM IR through llc.
>>>
>>> Sounds reasonable, but...
>>>
>>>
>>>> @@ -503,5 +510,12 @@ struct pipe_screen *radeonsi_screen_create(struct radeon_winsys *ws)
>>>>  	/* Create the auxiliary context. This must be done last. */
>>>>  	sscreen->b.aux_context = sscreen->b.b.context_create(&sscreen->b.b, NULL);
>>>>  
>>>> +	/* Initialize LLVM TargetMachine */
>>>> +	r600_target = radeon_llvm_get_r600_target();
>>>> +	sscreen->tm = LLVMCreateTargetMachine(r600_target, "r600--",
>>>> +				r600_get_llvm_processor_name(sscreen->b.family),
>>>> +				"+DumpCode", LLVMCodeGenLevelDefault, LLVMRelocDefault,
>>>> +				LLVMCodeModelDefault);
>>>> +
>>>>  	return &sscreen->b.b;
>>>>  }
>>>
>>> ... since you pass "+DumpCode" here, the MachineInstrs are actually
>>> always dumped unconditionally. With that fixed, this patch is
>>>
>>
>> I've removed the MF.dump() call in the LLVM tree, so this won't happen.
> 
> That won't help people using LLVM 3.4 (or 3.5?), will it?

Tom, users of LLVM 3.4/5 get spammed by MachineInstr dumps with this
change, right? Do you have a plan to address this?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer