I mean maybe, sure? I don't think that's their end goal, as their main purpose is to have a gcc version for gcc folks, whether it's faster or slower than llvm isn't a goal though. I think first goal is to get it done and stable and forces in place to keep up with the ever updating Rust spec(s). It would also allow for a much wider number of platforms as gcc compiler is much higher coverage of platforms especially legacy ones.
I doubt it, specially if you compare agains the GCC rustc backend. I would expect most of the difference (If any) to come from the frontend. For example, if it doesn't do borrow checking, it might be able to shave off a bit of time. But at that point, it highly depends on the workload (i.e the code you're compiling). I would expect the vast majority of rust code to bottleneck on codegen, in which case there should be approximately 0 difference. For code bottlenecked on borrow checking (Which I would expect to be an outlier), gccrs should be faster while ignoring borrow checking (Although my understanding is they plan to eventually use polonius for borrow checking, a rust library/project that originally intended to replace the current borrow checker in rustc but still hasn't. In which case, it would probably be faster for some borrow checking and slower for others)
No. LLVM is faster than GCC so most likely it'll be slower. If the way the frontend generates code for the backend is completely different then there's a chance it won't be terrible and will have reasonable build speeds. However there's a chance it'll be inconsistent with llvm output but chances are noone will notice or care if it's not buggy