[llvm-dev] Calling LowerSwitchPass causing crash in llvm 9

[n3v3rm03 via llvm-dev]

My question is that Is there any policy to decide if I should or should not
call LowerSwitchPass? Anyway, I already have some assumption. Maybe if the
backend support to translate switch instructions into binary tree or switch
table, then it's not necessarily to call LowerSwitchPass in frontend. And
it seems most backend
support this.

On Fri, Dec 27, 2019 at 4:10 PM n3v3rm03 <n3v3rm03 at gmail.com> wrote:

> No, I'm not talking about object code, I'm talking about llvm-ir. And
> there IS "switch" instruction in llvm-ir.
>
> 2019年12月27日(金) 15:50 mayuyu.io <admin at mayuyu.io>:
>
>> There is no “switch” instruction in the target object code. It usually
>> gets compiled into a switch table with instructions to load from it. Afaik
>>
>> Zhang
>>
>> 在 2019年12月26日，17:49，n3v3rm03 via llvm-dev <llvm-dev at lists.llvm.org> 写道：
>>
>> Sorry I found an early thread discussing this question. I guess I
>> shouldn't create lower switch pass like this.
>> However, I have another question, even if I don't  call this pass, the
>> switch instructions will be finally compiled into binary trees, is that
>> correct?
>> It seems only AMDGPU is using this pass. Is there any rule to call this
>> pass or not?
>>
>> On Thu, Dec 26, 2019 at 6:36 PM n3v3rm03 <n3v3rm03 at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I am trying to call LowerSwitchPass directly in my custom pass in this
>>> way:
>>>
>>>
>>>   FunctionPass *lower = createLowerSwitchPass();
>>>   lower->runOnFunction(*f);
>>>
>>> But it will crash when running lower->runOnFunction(*f) in llvm-9.
>>> I was using this method in llvm-8 and it worked fine. It seems the crash
>>> happens at the first line of the LowerSwitch::runOnFunction(Function &F) in
>>> the newer llvm:
>>>
>>> LazyValueInfo *LVI = &getAnalysis<LazyValueInfoWrapperPass>().getLVI();
>>> //crashed here
>>>
>>> I can't figure out why this usage cause the compiler to crash? Am I
>>> calling function pass wrong?
>>>
>>> Thank you for your help.
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191227/d0ccae3b/attachment.html>