On 2 August 2017 at 10:17, Mun, Gwan-gyeong wrote:
> Hi Jason,
>
> thanks for your kind explanation.
>
> I has totally understood your intention.
>
> ( I don't mean to bother you, at first I just wanted to silence of
> below coverity warning.
>
Hi Jason,
thanks for your kind explanation.
I has totally understood your intention.
( I don't mean to bother you, at first I just wanted to silence of
below coverity warning.
---
On July 25, 2017 8:16:42 PM "Mun, Gwan-gyeong" wrote:
Hi Jason,
You are right, as you commented, compilers can eliminate these redundancies
easy.
However I think we don't need to generate redundant codes.
The approach we generally take with generators like this is to not really
care too much
Hi Jason,
You are right, as you commented, compilers can eliminate these redundancies
easy.
However I think we don't need to generate redundant codes.
Best regards,
Gwan-gyeong
2017년 7월 26일 (수) 오전 12:34, Jason Ekstrand 님이 작성:
> Does the redundancy ends up mattering in any way? A decent optimizi
Does the redundancy ends up mattering in any way? A decent optimizing
compiler should easily be able to get rid of that for you.
--Jason
On July 25, 2017 2:51:31 AM Gwan-gyeong Mun wrote:
Before, it generates functions like this,
static inline uint32_t ATTRIBUTE_PURE
RENDER_SURFACE_STATE_
Before, it generates functions like this,
static inline uint32_t ATTRIBUTE_PURE
RENDER_SURFACE_STATE_RedClearColor_start(const struct gen_device_info *devinfo)
{
switch (devinfo->gen) {
case 10: return 384;
case 9: return 384;
case 8: return 255;
case 7:
if (devinfo->is_haswel
